Systems, methods and computer program products for monitoring credit risks in electronic trading systems

ABSTRACT

A credit monitoring system in an electronic trading system forms a complex check to determine if two particular counterparties will except each other for a particular trade based upon their respective predefined credit preferences. In accordance with an embodiment, credit preferences imputed by each counterparty with regard to the other counterparty are referenced to determine the trade eligibility of either party with respect to the other for a particular financial transaction instrument. Indication of whether a counterparty can enter into the proposed trade is conveyed to the respective trader, preferably using a color coding scheme in which various colors represent the relevant credit status with regard to the viewing trader. The complex check performed by the system may be embodied in a simple yes/no statement, in terms of maturity of a particular financial instrument, or in terms of a risk quotient (i.e., risk equivalent or RQ) initially determined by the system, though modifiable by the trader.

FIELD OF THE INVENTION

[0001] The present invention generally relates to brokerage systems andmethods, and more particularly, to credit risk screening of potentialcounterparties before conducting trades via an electronic tradingsystem.

BACKGROUND OF THE INVENTION

[0002] In recent years, commodity exchanges have become more and moredependent upon electronic trading systems. The older manual methods bywhich trades were conducted have given way to advanced computer systemsthat have generally mimicked the manual methods of old. These relativelynew electronic trading systems have many advantages over the manualsystems, including the ability to provide such features as greateraccuracy, reduced labor cost, real time market information, moreefficient communications over greater distances, and automated recordkeeping. However, because the markets in which these commodities arebeing traded are so vastly different from the descriptions of theinstruments to transaction methodologies, electronic trading systems aregenerally limited to a specific market such as futures, cash, oil,stock, securities, etc., and sometimes even to a specific commoditywithin a single market.

[0003] An example of one such automated trading system designed for theanonymous trading of foreign currencies is described in U.S. Pat. Nos.5,077,665 and 5,136,501, both issued to Silverman et al. and assigned toReuters Limited of London. In the Silverman et al. system, a singlecentral host computer maintains a central data base that may consist ofthe trading instruments available for trade, credit information, andvarious bids and offers that are present throughout the system. The hostcomputer may then use this information to match active bids and offersbased on matching criteria which may include the gross counterpartycredit limit between counterparties to a potential matching transaction,price, and available quantity. To that end, each client site mayestablish, and may subsequently vary or reset, a credit limit for eachpossible counterparty. The credit limits may be used by the hostcomputer to establish the gross counterparty credit limit for eachpossible pair of parties and which may be equal to the minimum of theremaining credit (i.e., initial credit limit less any applicabletransactions that have already been executed) from a first party to asecond party and from the second party to the first party. The hostcomputer may block completion of an otherwise eligible matchingtransaction between a given pair of potential counterparties when thetransaction has an associated value in excess of the applicable grosscredit limit. In the Silverman et al. system, the various client sitecomputers (also referred to as keystations) merely maintain and displaya restricted subset of the information available at the host computersuch as a predetermined number of the best bids and offers, andcommunicate credit and other transaction orientated information to thehost computer for execution. However, in an attempt to preserve theanonymity of the parties, the client sites may not have access to thecredit limits set by their possible counterparties, or even to theidentification of any other party to a particular transaction untilafter a transaction has been completed.

[0004] Thus, in the Silverman et al. system, confidential counterpartycredit limit data is apparently maintained and utilized as part of thetrade matching process by the central host computer. As a consequence,each client site may not have the ability to determine, prior tocommitting to buy or sell at a displayed price from one or moreanonymous counterparties, whether it is in fact eligible to respond toany of the bids or offers currently being displayed. Further, the creditlimit appears to be merely a cap value (or credit line) on the amount oftrading one party will enter into with another party. It has little tono relationship to the credit risk the other party represents since thefinancial commitment associated with the financial instruments tradedwith this system ends at the consummation of the underlying contract,.Thus, a cap value may be sufficient in this particular circumstance. Thecentral host computer may not utilize the credit information until aftera match has been found between counterparties to determine if thecounterparties have sufficient credit with one another to execute thetrade.

[0005] Consequently, unless a trader attempts to execute a trade at thebest price currently displayed on the trader's screen, the trader usingone of the anonymous matching systems may not know whether the traderhas credit with, and is willing to extend credit to, the anonymouscounterparty offering (i.e., bidding) the best price currently displayedon the trader's screen. Thus, the trader does not know whether anyattempt to buy or sell at the displayed price may be subsequentlyinvalidated by the system for lack of such credit. The Silverman et al.system also fails to provide for dialogue between the parties, much lessanonymous dialogue which may facilitate the execution of a trade thatmight otherwise not occur.

[0006] Another automated trading system is disclosed in U.S. Pat. No.5,375,055 issued to Togher et al. and assigned to Foreign ExchangeTransaction Services, Inc. The Togher et al. system is an anonymoustrading system which may identify the best bids and offers from thosecounterparties with which each client site is currently eligible todeal, while maintaining the anonymity of the potential counterparty andthe confidentiality of any specific credit limitations imposed by theanonymous potential counterparty. This system is apparently designed torun as a closed system, with dedicated desk top terminals connected tovarious local computer centers which are in turn connected to regionalcomputers.

[0007] In the Togher et al. system, each client site may only be able toview one foreign currency at a time per screen. The Togher et al. systemis further limited by the fact that each client site may provide thesystem with only limited credit information for each potentialcounterparty (for example, a one bit flag indicating whether apredetermined limit has already been exceeded), and by the fact thateach bid or offer for a particular type of financial instrument isapparently prescreened by the system for compatibility with that limitedcredit information before calculating an anonymous dealable price forpresentation to the traders dealing with that particular financialinstrument. The prescreening in Togher et al. is a simple check todetermine whether any credit remains between the two counterparties tothe potential transaction, and thus may be performed using a simpleyes/no preauthorization.

[0008] The preauthorization matrixes may be maintained at each of theseveral regional nodes (also referred to as distributed nodes) of adistributed processing communication network, with each such regionalnode being connected by corresponding individual links of thecommunications network to the respective client sites (“access nodes”)for which it is responsible for distributing market informationincluding customized dealable bid and offer prices and global bestprices.

[0009] The sensitive credit limit data indicating how much credit aparticular client site is willing to extend to each possiblecounterparty is preferably maintained at an access node associated withthat particular client, and a simple yes/no indication of whether theentity (for example, a trader, a trading floor, or a bank) associatedwith that particular client site is willing to transact business with aparticular counterparty is transmitted to the other nodes of thecommunications network.

[0010] To further limit the data received and processed by each of therelevant regional node computers, (i.e., the regional nodes closest tothe particular site and/or closest to the particular counterparty),merely the changes in the credit state between a particular client siteand a particular counterparty (i.e., that credit is no longer availableor credit is now available) may be transmitted to the distributionnodes, and any credit state information relevant to transactions betweentwo client sites both associated with other distribution nodes may bealtogether ignored.

[0011] In the Togher et al. system, if either of the two applicablecredit limits has not previously been exceeded between a particular pairof counterparties, then the system displays the entire bid or offer as adealable transaction, but apparently permits each client site to blockany above-limit portion of any resultant buy or sell transaction duringa subsequent deal execution/verification process. This may, however, addadditional time consuming steps for the users of the Togher et al.system. Alternatively, possibly at the option of the party by or forwhom the low limit has been set, the entire transaction may be blocked.As a second alternative, a preauthorization matrix may indicate whethersufficient credit remains to execute a predetermined standard dealamount in addition to, or instead of, a mere indication as to whetherany credit from a particular potential counterparty had already beenused up. In such an alternate embodiment of the Togher et al. system, itmight also be possible to display to each trader two dealable prices:one at which at least the predetermined standard amount is available,and a second one at which only a small amount may be available. Thus,individual orders are not independently treated, and the user may nothave the ability to look through the bids and offers and deal at a worstprice, if the user so chooses because of a difference in counterpartiescredit qualities.

[0012] In accordance with another aspect of the Togher et al. system, atleast a first trader having an open quote that is displayable as thebest dealable or regular dealable quote at any of the other tradingfloors is automatically alerted that their bid (offer) quotation is thebest price available to at least one potential counterparty with whommutual credit exists, and thus could be hit (taken) at any time.Similarly, at least if the quoter's bid (offer) quote is not currentlythe best with at least one trading floor but is thus subject toimmediately being hit (taken) by a trader at that trading floor, thenthe quoter is preferably also alerted if his/her quote is joined (i.e.,equal to in price, but later in time) to such a best dealable or regulardealable price from another trading floor. In other words, in the Togheret al. system, the auto-matching process does not enable the activetrader to select a price other than the best price to trade. This mayforce the trader to accept what the system offers, even if the traderwould prefer a different counterparty for credit reasons. In addition,the Togher et al. system does not show the trader the total depth of themarket, only those prices which are dealable, and thus, may fail to givethe trader complete picture of the market. The is also limited to thequantity stated. No provision is made for the modification ornegotiation of the quantity or other terms of the trade.

[0013] The systems described above are such that they focus on overnightsettlement risk. These systems are apparently incapable of dealing withthe actual credit requirements of a variety of different individualfinancial instruments simultaneously and the counterpart's long-termability to meet these requirements. As a result, these systems generallyhave only been deployed in the markets where settlement takes place in afew days and there are no continuous or ongoing credit requirementsbetween the counterparties. Specifically, as a result of theselimitations, these designs may not be able to handle the anonymoustrading of financial instruments such as interest rate swaps, caps andmany other financial products. They may be unable to accommodate thesemore complex financial instruments because, among other things, thesesystems apparently treat all financial instruments alike, and therefore,may be incapable of handling more complex financial instruments whichrequire a judgment about the financial strength of the opposingcounterparties. Trades conducted with some financial instruments such asderivatives create multi-year financial commitments, and therefore, merecredit limit or credit cap systems are insufficient means for measuringand managing an institution's credit risk.

[0014] Accordingly, it is noted that no known system is designed tooperate with derivative products such as interest rate swaps, caps,floors, forward rate agreements (FRA), interest rate basis swaps,interest rate options, switches, or other over the counter derivativeinstruments. Derivatives are considered by many to be too complex to beefficiently handled within an electronic trading system. Particularly,derivative products are typically define by certain terms andconditions, and each of the different types of derivatives products aredefined by a different set of terms and conditions. For example, an FRAis defined by a start time, an end time, an over date, and a floatingrate option, while an interest rate swap is defined by a start time, anend time, an over date, a floating rate option, a frequency of the fixedcoupons, a basis, and a special rule(s) as applicable with somecurrencies. Accordingly, the variances in the specific informationnecessary to adequately define the different derivative products hasapparently been a deterrence to the development of an electronicderivatives trading system.

[0015] Yet another deficiency of the prior art systems is the inabilityto automatically determine one's position (i.e., credit risk position),and the inability to identify possible counterparties with offsettingpositions for initiating a transaction. No know electronic tradingsystem has been able to provide this information on a real-time basis.This strikes to the essence of the derivatives market which is basedupon large financial institutions to being able to manage their creditrisk on a daily basis.

[0016] A further limitation of the known electronic trading systemswhich has contributed as a deterrence to their application to thederivatives market is the absence of an acceptable credit screeningprocess of potential counterparties in a manner which accommodates thenuances of the derivatives market. While many of the prior artelectronic trading systems such as the ones described above provide acredit screening feature, they typically only track the amounttransacted between two parties, and upon each transaction between thetwo parties, reduces the available amount according to the amount of thetransaction. Thus, the credit risk measured by these systems is based onthe principle or quantity of the transaction. No consideration is givento the future obligations under the contract.

[0017] In the derivative market, a counterparty's credit position mayvary with each new transaction conducted with other parties. The priorart systems do not account for such changes in a counterparty'sposition. Further, the credit qualities associated with derivativeproducts are generally more complex than most other financialinstruments. For example, a particular trader may be willing to tradewith a particular counterparty on one type of financial instrument butnot another. Further, a trader may accept that one type of financialinstrument but only for a certain length of time (i.e., maturity).

[0018] Thus, a heretofore unresolved need exist in the industry for asystem and method for anonymous credit screening of potentialcounterparties before conducting trades via an electronic trading systemwherein the credit risk preferences of the trader take into account thecomplexity of the different types derivatives instruments.

SUMMARY OF THE INVENTION

[0019] It is therefore an object of the present invention to provideimproved credit screening for electronic trading systems.

[0020] It is another object of the present invention to provideanonymous bi-lateral credit screening which determines trade eligibilitybased on both trader's credit preferences.

[0021] It is another object of the present invention to provide creditpreference screening which considers the amount and maturity of eachfinancial instrument being traded.

[0022] These and other objects of the present invention are provided fora credit monitoring system that forms a complex check to determine iftwo particular counterparties will accept each other for a particulartrade based upon their respective predefined credit preferences. Inaccordance with an embodiment of the present invention, creditpreferences inputed by each counterparty with regard to the othercounterparty are referenced to determine the trade eligibility of eitherparty with respect to the other for a particular financial transactioninstrument. Indication of whether a counterparty can enter into theproposed trade is conveyed to the respective trader, preferably using acolor coding scheme in which various colors represent the relevantcredit status with regard to the viewing trader. The complex checkperformed by the system may be embodied in a simple yes/no statement, interms of maturity of a particular financial instrument, or in terms of arisk quotient (i.e., risk equivalent or RQ) initially determined by thesystem, though modifiable by the trader. Accordingly, financialinstitutions which trade complex financial instruments such asderivatives which create obligations which extend into the future maybetter monitor their credit risk by the bilateral credit screening ofthe present invention. Particularly, the multilevel credit preferenceswhich each trader may utilize in establishing credit preferences withregard to other counterparties enables greater control and flexibilityin the trading of complex financial instruments. It is further notedthat the credit check process is performed anonymously so as not toidentify potential counterparties to a deal until after the trade isagreed to by both parties.

[0023] In accordance with an aspect of the present invention, a systemfor credit screening an electronic trade of a financial instrumentbetween a first trader and a second trader comprises means for receivingfirst credit preference information of the first trader with respect tothe second trader, wherein the first credit preference informationrelates to at least one financial instrument. The system furthercomprises means for receiving second credit preference information ofthe second trader with respect to the first trader, wherein the secondcredit preference information relates to at least one financialinstrument, and means for evaluating the first and second creditpreferences with respect to a trade of a first financial instrument todetermine respective trade eligibility of the first and second tradersto trade with each other. The system further comprises means forreporting the respective trade eligibility to the first trader and thesecond trader.

[0024] The means for reporting may include a first indicationrepresenting that the first and second traders will trade with eachother, a second indication representing that the first trader will tradewith the second trader but the second trader will not trade with thefirst trader, and a third indication representing that the second traderwill trade with the first trader but the first trader will not tradewith the second trader. In addition, the means for reporting may includea color coding scheme for presenting the first, second and thirdindications respectively to the first and second traders. The colorcoding scheme may include a first color associated with the firstindication, a second color associated with the second indication, and athird color associated with the third indication.

[0025] The credit preference information may defined in terms of ayes/no statement, a maturity of a financial instrument, or a riskequivalent. The risk equivalent is preferably automatically determinedby said system. In accordance with a feature of the present invention,the first and second credit preference information is maintained inanonymity. The first and second credit preference information may beupdated in essentially real-time by the first and second traders,respectively.

[0026] In accordance with another aspect of the present invention, amethod for credit screening order information proposing a trade of afinancial instrument via an electronic trading system comprisesreceiving first credit preference information defined by a first traderwith respect to a second trader, receiving second credit preferenceinformation defined by the second trader with respect to the firsttrader, and encoding the order information presented to the first andsecond traders utilizing the first and second credit preferenceinformation.

[0027] The method may further comprise modifying the first creditpreference information by the first trader. The step of encodingincludes a first indication representing that the first and secondtraders will trade with each other, a second indication representingthat the first trader will trade with the second trader but the secondtrader will not trade with the first trader, and a third indicationrepresenting that the second trader will trade with the first trader butthe first trader will not trade with the second trader.

[0028] The first credit preference information and the second creditpreference information may be defined as preferences with regard to atleast one financial instrument. In accordance with a feature of thepresent invention, the method may further include maintaining the firstand second credit preference information in anonymity.

[0029] In accordance with yet another aspect of the present invention, acomputer program product for use with a data processing system forcredit screening order information proposing a trade of a financialinstrument via an electronic trading system comprises a computer usablemedium having computer-readable code means embodied in said medium,wherein the computer-readable code means comprises computer readableprogram code means for receiving first credit preference information ofthe first trader with respect to the second trader. The computer programproduct further comprises computer readable program code means forreceiving second credit preference information of the second trader withrespect to the first trader, computer readable program code means forevaluating the first and second credit preferences with respect to atrade of a first financial instrument to determine respective tradeeligibility of the first and second traders to trade with each other,and computer readable program code means for reporting the respectivetrade eligibility to the first trader and the second trader.

BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The file of this patent contains at least one drawing executed incolor. Copies of this patent with color drawings will be provided by thePatent and Trademark Office upon request and payment of the necessaryfee.

[0031]FIG. 1 is a schematic diagram of a computer network implementingan electronic trading system in accordance with an embodiment of thepresent invention.

[0032]FIG. 2 is a block diagram illustrating the architecture andfunctionality of a central processing center in accordance with anembodiment of the present invention.

[0033]FIG. 3 is a block diagram illustrating the architecture andfunctionality of a trader system in accordance with an embodiment of thepresent invention.

[0034]FIG. 4 is a block diagram illustrating the architecture andfunctionality of a business unit proxy in accordance with an embodimentof the present invention.

[0035]FIG. 5 is an example of a command center interface.

[0036] FIGS. 6A-6B are examples of different tabbed partitions of a userpreference interface.

[0037]FIG. 7 is an example of a credit preference setting interface.

[0038]FIGS. 8A and 8B are examples of different tabbed partitions of amodify credit groups interface.

[0039]FIGS. 9A and 9B are examples of the new binary interface andcomplex preference interface respectively, which are accessible from thecredit preference setting interface.

[0040]FIG. 10 is an example of a business unit information interface.

[0041]FIG. 11 is an illustration of the credit preference logic of anembodiment of the present invention.

[0042]FIG. 12 is an example of a market entry interface.

[0043]FIG. 13 is an example of a symbol definition interface.

[0044]FIG. 14A is an example of an passive order interface.

[0045]FIG. 14B is an example of an hit order interface.

[0046]FIG. 15 is an example of a market detail interface.

[0047]FIG. 16 is an example of an outstanding order blotter interface.

[0048]FIG. 17 is an example of a client monitor interface.

[0049]FIG. 18 is an example of a execution notification and quantitynegotiation interface.

[0050]FIG. 19 is an example of a term negotiation interface.

[0051]FIG. 20 is an example of a user position portfolio interface.

[0052]FIG. 21 is an example of a switch interface.

[0053]FIGS. 22A and 22B are examples of an auction interface and aswitch auction interface, respectively.

[0054]FIG. 23 is an example of a main screen interface in accordancewith an embodiment of the present invention.

[0055]FIG. 24 is a flowchart of the credit preference feature inaccordance with an embodiment of the present invention.

[0056]FIG. 25 is a flowchart of the subject based addressing feature inaccordance with an embodiment of the present invention.

[0057]FIG. 26 is a flowchart of the execution of a trade in accordancewith the embodiment of the present invention.

[0058]FIGS. 27A and 27B are flowcharts of a trade execution from theperspective of the user posting the order and the user acting on theorder, respectively, and in accordance with an embodiment of the presentinvention.

[0059]FIG. 28 is a flowchart of the position discovery feature inaccordance with an embodiment of the present invention.

[0060]FIG. 29 is a flowchart of the auction feature in accordance withan embodiment of the present invention.

[0061]FIG. 30 is a detailed flowchart of the auction feature inaccordance with an embodiment of the present invention.

[0062]FIG. 31 is a flowchart of the calculation of the average auctionprice in accordance with an embodiment of the present invention.

[0063]FIG. 32 is a flowchart of the matching performed in an auction inaccordance with an embodiment of the present invention.

[0064]FIG. 33 is a flowchart of the validation of a resulting order inan auction in accordance with an embodiment of the present invention.

[0065]FIG. 34 is a process flow diagram illustrating operations andfunctionality of the central processing center in accordance with anembodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0066] The present invention now will be described more fullyhereinafter with reference to the accompanying drawings, in whichpreferred embodiments of the invention are shown. This invention may,however, be embodied in many different forms and should not be construedas limited to the embodiments set forth herein; rather, theseembodiments are provided so that this disclosure will be thorough andcomplete, and will fully convey the scope of the invention to thoseskilled in the art. Like numbers refer to like elements throughout.

[0067] I. Introduction

[0068] The following description is of a best-contemplated mode ofcarrying out the present invention. The systems, methods, and computerprogram products of the present invention have practical application inanonymously trading a very broad cross-section of credit-sensitive,bilateral financial instruments. However, a particular application ofthe present invention described hereinafter is directed to the use ofthe present invention for trading financial instruments in thederivatives market. The scope of the present invention should not belimited to that described hereinafter, but should be determined byreferencing the appended claims.

[0069] The present invention provides for a standardized contractdefinition, and means for matching complex credit preferences of eachcounterparty before a trade is executed. Therefore, potentialcounterparty users are able to identify bids and offers that they areeligible to trade based on credit preference information provided beforeinitiating a trade. The present invention also permits users to placepassive orders (bids or offers on the various financial products forother counterparties to actively choose from to hit (bids) or lift(offers), without the posting user doing anything further) or activeorders (where the viewing user actively initiates the trade by selectingpassive bids or offers which are already in the system). This gives auser maximum control over the order flow process. For instance, theremay be a situation whereby the bids in a particular market are higherthan the offers, but no trading is taking place. This situation mayoccur when the credit quality of the best offer (which in this casewould be below the bid) would not be good enough for a bidder to bewilling to enter into a transaction with that counterparty. This is asignificant difference from the prior art systems in which orders areautomatically matched if the prices are equal because such prior artsystems typically limited the user's control over the order flow.

[0070] The present invention also provides financial markets withelectronic trading systems and methods for identifying possiblecounterparties and executing trades for forward rate agreement (FRA)switches and other financial products. The present invention furtherprovides the ability for the users to place orders for various financialinstruments via an auction process that can be one-to-many ormany-to-many, whereby the system automatically matches all orders anddetermines the prices and quantities executed on the basis of severalguidelines or parameters. A further feature of the present invention isan auction trading that is available to users, whereby users can use anauction process to trade FRA switches with the other counterparties.This form of auction is referred to hereinafter as a switch auction. Inthe auctions, the price is preferably pre-determined by the system priorto the auction taking place. The prices determined by the system arereferred to hereafter as the fair price.

[0071] The systems and methods of the present invention are designed toreflect the fact that financial institutions operate under manydifferent structures. In order to accomplish this, the followingconcepts/definitions are provided:

[0072] Legal Entity (LE):

[0073]  This is the incorporated entity in which contracts arenegotiated on behalf of by users (traders) of the system.

[0074] Business Unit (BU):

[0075]  This is a grouping of individual users within a Legal Entitythat act together and share attributes such as LE, manager, address,settlement information, credit preferences (see below), etc.

[0076] Risk Equivalent (RQ):

[0077]  This is the unique measure of Risk associated with financialcontracts such that contracts with different attributes can be comparedon a like basis for credit risk purposes.

[0078] Credit Preferences (CP):

[0079]  This is the model which allows the system to handle differentmeasures of risk equivalent used by different institutions and differentfinancial contracts, all with different internal structures.

[0080] Classes of Financial Instruments (CL):

[0081]  These are collections of financial contracts which share similarattributes.

[0082] Credit Groups (CG):

[0083]  A method to allocate credit preferences across classes offinancial contracts.

[0084] User Preferences (UP):

[0085]  A method to allow institutions or users to control or manageaccess to the functions within the system.

[0086] Filters (FI):

[0087]  These allow users to limit the messages (i.e., request for priceor request for switch they receive or view.

[0088] Symbology (SY):

[0089]  This enables users to quickly and easily reference financialcontracts within the system in a systematic manner.

[0090] Term Negotiation (TN):

[0091]  This is a method which allows users to negotiate non-commercialterms of contract subsequently to a trade. For example, the exchange ofbonds relating to a spread trade.

[0092] Credit Over-Ride Process:

[0093]  This process enables a user to disclose his/her identity to acounterparty to see if they will accept a trade with him/her even thoughthey initially refused him due to credit issues.

[0094] Comprehensive Confirmations:

[0095]  This is a confirmation lay-out in order to fully definebilateral contracts across any classes of financial instruments.

[0096] Request For (RF)

[0097]  This is a method to broadcast to the other users (subject totheir FI) an interest in a price or market.

[0098] II. System Architecture

[0099] As will be appreciated by one of ordinary skill in the art, thepresent invention may be embodied as a method, a data processing system,or a computer program product. Accordingly, the present invention maytake the form of an entirely hardware embodiment, an entirely softwareembodiment or an embodiment combining software and hardware aspects.Furthermore, the present invention may take the form of a computerprogram product on a computer-readable storage medium havingcomputer-readable program code means embodied in the storage medium. Anysuitable computer readable storage medium may be utilized including harddisks, CD-ROMs, optical storage devices, or magnetic storage devices.

[0100] The present invention is described below with reference to blockdiagrams and flowchart illustrations of methods, apparatus (i.e.,systems) and computer program products according to an embodiment of theinvention. It will be understood that each block of the block diagramsand flowchart illustrations, and combinations of blocks in the blockdiagrams and flowchart illustrations, respectively, can be implementedby computer program instructions. These computer program instructionsmay be loaded onto a general purpose computer, special purpose computer,or other programmable data processing apparatus to produce a machine,such that the instructions which execute on the computer or otherprogrammable data processing apparatus create means for implementing thefunctions specified in the flowchart block or blocks.

[0101] These computer program instructions may also be stored in acomputer-readable memory that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablememory produce an article of manufacture including instruction meanswhich implement the function specified in the flowchart block or blocks.The computer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer implemented process such that theinstructions which execute on the computer or other programmableapparatus provide steps for implementing the functions specified in theflowchart block or blocks.

[0102] Accordingly, blocks of the block diagrams and flowchartillustrations support combinations of means for performing the specifiedfunctions, combinations of steps for performing the specified functionsand program instruction means for performing the specified functions. Itwill also be understood that each block of the block diagrams andflowchart illustrations, and combinations of blocks in the blockdiagrams and flowchart illustrations, can be implemented by specialpurpose hardware-based computer systems which perform the specifiedfunctions or steps, or combinations of special purpose hardware andcomputer instructions.

[0103] A trading system in accordance with the present invention is anelectronic brokerage system which may use Internet protocol-basedcommunications networks for facilitating the trading (i.e., buying andselling) of financial derivatives by users, each of which is associatedwith the user's own desktop computer system (trader system) located onthe trading floor of a financial institution (client site), as describedbelow. At the user's desktop computer system, the present invention ispreferably implemented by a Java-based software program, though othersuitable program languages can be utilized such as dynamic hypertextmarkup language (DHTML), C+ or C++.

[0104] As shown in FIG. 1, a trading system 10 in accordance with thepresent invention comprises a central processing center 12 which is incommunication with the client sites 14 via one or more of a variety ofInternet protocol based networks 16. By way of illustration, a privateextranet, a public Internet, and a third party extranet are show, thoughit will be recognized by those skilled in the art that other networkssuch as the Public Switch Telephone Network (PSTN) may be implemented asa network 16. Further, by having multiple networks 16 available, theuser is provided redundancy in case one network experiences a serviceinterruption, and the user is able to choose between the severalnetworks 16 for primary access based on factors such as toll charges orbandwidth.

[0105] Each client site 14 includes one or more business unit servers 18which, among other things, can store copies of the Java applets whichcan be utilized to implement the present invention. The business unitservers 18 may also perform encryption/decryption functions for messagesthat are received and sent over the networks 16. The business unitservers 18 are preferably connected to the client sites 14 internal datanetwork. Thus, one or more trader workstations 20 may be connected to abusiness unit server 18 of a client site 14. Accordingly, a user's owndesktop computer which is connected to the client's internal datanetwork may function as a trader workstation 20 and run the Java-basedsoftware of the present invention to enable interaction with othertrader workstations 20 via the central processing center 12.

[0106] With reference to FIG. 2, illustrated is the central processingcenter 12 which includes a trade mechanism 30, a group server mechanism32, auction mechanism 34, and a switch mechanism 35, all in accordancewith the present invention. The trade mechanism 30 includes severalmodules including a market inventory module 38, an execution module 40,and a settlement module 42. The market inventory module 38 holds thepassive orders for each market and broadcast the same to the traderworkstations 20 when new orders are received, validates any proposedtrade, performs a second and final credit preference check that cannotbe performed at the trader workstation 20, validates that both tradersare still on-line (i.e., active), executes the trade, and sends out astatus update to the traders. The execution module 40 receives theexecuted trade and proposes a trade for a greater quantity if applicable(referred to as the will-do-more feature), and processes termnegotiation if applicable. The settlement module 42 calculates theappropriate commission, generates the confirmation, and sends theconfirmation to the two parties.

[0107] The group server mechanism 32 interfaces the trader module 30with the trader workstations 20. The central processing center 12 mayinclude a plurality of group server mechanisms 32, each of whichpreferably serves a subset of the users (i.e., trader workstation) ofsystem 10, though the system 10 may be implemented with only one groupserver mechanism 32. The group server mechanism 32 monitors theconnection of each trader workstation 20 so that log-in and log-outtimes and usage can be monitored. The group server mechanism 32 alsocaches market information being viewed at each trader workstation 20 andcreate an order identification code that uniquely identifies that order.The credit preference information of all users is cached in by the groupserver mechanism 32 for delivery to each trader workstations 20 when theassociated user logs in. Any changes in the credit preference setting bya trader are detected and forwarded to the trader workstations 20 of theother users.

[0108] The switch mechanism 35 is configured to receive a portfolio ofinterest reset risk for a plurality of users and provide the users withan anonymous view at their relative position to other possiblecounterparties and available trades that may offset the user's interestrate reset risk. The auction mechanism 34 performs a switch auctionfunction whereby orders or FRA's are received from the users andanonymously matched based on an algorithm that takes user creditpreferences into consideration.

[0109] The trader mechanism 30, group server mechanism 32, auctionmechanism 34, and switch mechanism 35 may be collectively implemented asmarket module 44.

[0110] The central processing center 12 includes a processor 50 thatcommunicates with the other elements within the central processingcenter 12 via a system interface 52. An input devise 54, for example akeyboard or a pointing device, is used to input data from a user, and ascreen display device 56, for example, a monitor, is used to output datato the user. A memory 58 within a central processing center 12 includesthe market module 44 and a conventional operating system 60 whichcommunicates with the market module 44 and enables execution of themarket module 44 (including the trade mechanism 30, group servermechanism 32, and auction mechanism 34) by processor 50. An externalcommunication line 62 is provided to interface the central processingcenter 12 with other computer systems or computer-based devices such asnetworks 16. Lastly, a hard disk 64 may be provided as a persistencememory device, as well known to the industry. Preferably, a relationaldatabase 66 resides on the hard disk 64 for maintaining information suchas current state information for each trader workstations 20, user andbusiness unit data, financial instrument definitions, order states,transaction states, confirmation states, historical confirmation andtransaction data, credit preferences of all business units, andhistorical market data. Preferably, the relational database 66 is basedon structured query language (SQL) management system, as well known inthe industry.

[0111] With reference now to FIG. 3, illustrated is an embodiment of thetrader workstations 20 which includes a trader module 70 in accordancewith the present invention. The trader module 70 may be implemented as acomponent of a Java-capable Internet browser program 72, such asNetscape Communicator (Netscape Communication Company) or Microsoft®Internet Explorer (Microsoft Corporation) version 3.0 or higher. Thus,in a preferred embodiment, the trader module 70 is a Java-based programthat is downloaded as Java applets for each session and implemented by aJava virtual machine (JVM) 73 within the Internet browser 72. The JVM 73of the Internet browser program 72 may be a stand alone softwareapplication, a plug-in application, or a helper application, all ofwhich is well known in the art. The trader module 70 includes a marketinterface module 74, a credit preference module 76, a symbol module 78,switch module 80, and an auction module 81. The market interface module74 comprises one or more user interfaces for presenting information tothe user. In the context of the present embodiment, a user interface isprovided as a window within the context of the Internet browser program72. However, a user interface in accordance with the present inventionmay take many forms such as a three dimensional virtual reality worldbased on virtual reality modeling language (VRML), an audioreceiver/transmitter, or any other suitable form of interface betweenthe user and trader workstations 20. In a preferred embodiment, themarket interface module 74 comprises a control center interface, marketentry interface, market detail interface, switch interface, and auctioninterface, all of which are described in more detail hereinafter.

[0112] The credit preference module 76 receives the stored creditpreferences inputted by the user and stored at group server mechanism32. The stored credit preferences include preferences directed to theother business unit's legal entities, and the preferences inputted bythe other users directed toward the business unit's legal entity of thesubject user. As mentioned above, the credit preference information ispreferably stored in the database 66 (FIG. 2). The credit preferencemodule 76 may encode the order information being presented to the userwith the credit preferences of the user and the credit preferences ofcounterparty that posted the order. The credit preference module 76 alsoperforms a credit preference check for each order when a trade isinitiated. Because of the potential complexity associated with thedifferent types of credit methods offered by the present invention,portions of the credit check process may be performed by the marketinventory module 38 of the central processing center 12. The creditpreference module 76 at each trader workstation 20 comprises asimplified matrix of yes's and no's, and associated maturities. If thebusiness unit has selected an even more complex method (i.e., complex),a unit (such as a risk quotient, i.e., RQ) by maturity is also required.The trader workstation 20 will therefore not be able to determinewhether the full quantity can be traded. Thus, the market inventorymodule 38 repeats the credit check to ensure the very latest creditpreferences are used (in case of any latency in updating the creditpreferences at the trader workstations 20) and to complete any complexcredit preference check for quantity.

[0113] The symbol module 78 stores the symbol definitions utilized forthe subject-based addressing of the different financial instrumentstraded in the system 10. The symbol module 78 also provides means fordefining new symbols for use with the system 10. The switch module 80 isconfigured to receive interest rate reset risk portfolios from the userwhich are sent to the switch mechanism 35 at the central processingcenter 12. The relative position information generated by the switchmechanism 35 is returned to the switch module 80 which presents theposition information to the user via the market interface module 74. Theauction module 81 is configured to receive multiple or batch orders on asingle instrument at different price levels, and in case of a switchauction, to receive a interest rate reset risk portfolio from the user.The inputted orders or portfolio is sent to the auction server 34 at thecentral processing center 12 where the auction or switch auction,respectively, is performed. The resulting matches are returned to theauction module 81 which presents the results to the user via the marketinterface module 74.

[0114] The trader workstations 20 includes a processor 82 thatcommunicates with other elements within the trader via a systeminterface 84. An input device 86, for example, a keyboard or pointingdevice, is used to input data from the user, and a screen display device88, for example, a monitor is used to output data to the user. A memory90 within the trader workstations 20 includes the Internet browserprogram 72 (and thus, the trader module 70) and a conventional operatingsystem 94 which communicates with the Internet browser program 72 andenables execution of the Internet browser program 72 (and thus, thetrader module 70) by processor 82. It is noted, however, that the tradermodule is preferably implemented as a Java-based program that isdownloaded into memory 90 for the execution during a single session, andthe trader workstations 20 will not persistently store the trader module70. Further, as a Java-based program, the trader module 70 will beexecuted on a JVM 73 which is a component of the Internet browserprogram 72.

[0115] An external communication link 96 is provided to interface thetrader workstations 20 with other computer systems or computer-baseddevices such as respective business unit servers 18. Lastly, a hard disk98 may be provided as a persistent memory device, as well known in theindustry. It is noted that the trader workstation 20 may comprise adesktop computer system as previously mentioned, or alternatively, thetrader workstation 20 may comprise a portable computing device such as anotebook computer, handheld PC, personal digital assistant (PDA) or anyother suitable device capable of running an Internet browser program andcreating a communication link for interfacing with a network.

[0116] Therefore, a user of the system 10 is not necessarily tied to aspecific hardwired terminal, but has a virtual terminal that goes withthe user wherever the user has access to a Java capable browser andInternet access. The trader module 70 may be implemented as anindependent program capable of establishing a communication link to thecentral processing center 12 via the Internet, a local area network(LAN), or a wide area network (WAN). Thus, the user can even have accessto the system 10 via direct modem dial-in to the central processingcenter 12 over the public switched telephone network (PSTN) or Internet.

[0117] With reference now to FIG. 4, illustrated is an embodiment of abusiness unit server 18 which includes a proxy agent 110 in accordancewith the present invention. The proxy agent 110 may perform numerousfunctions including decoding and encoding encrypted messages sent andreceived over networks 16. The proxy agent 110 manages traffic to andfrom the trader workstations 20, and may provide other features such asdocument caching and network access control. The proxy agent 110 mayimprove performance by storing and supplying frequently requested datato the trader workstations 20, or by filtering and/or discardinginformation from the networks 16. Preferably, proxy agent 110 resides ona business unit server 18 which is part of the respective client sites14 internal data networks. However, the system 10 of the presentinvention may be implemented without business unit servers 18, wherebythe functionality of the proxy agent 110 may be incorporated into thetrader module 70 of the respective trader workstation 20; suchfunctionality including decoding and encoding encrypted messages, andnetwork management.

[0118] The business unit server 18 includes a processor 112 thatcommunicates with the other elements within the business unit server 18via a system interface 114. An input device 116, for example, a keyboardor pointing device, is used to input data from a user, and a screendisplay device 118, for example, a monitor, is used to output data tothe user. A memory 120 within the business unit server 18 includes theproxy agent 110 and a conventional operating systems 122 whichcommunicates with the proxy agent 110 and enables execution of the proxyagent 110 by processor 112. An external communication link 124 isprovided to interface the business unit server 18 with other computersystems or computer/based machines such as networks 16 and traderworkstations 20. Lastly, a hard disk 126 may be provided as apersistence memory device, as is well known in the industry.Particularly, the hard disk 126 may include trader data profiles 128 foreach of the different trader workstations 20 associated with thebusiness unit server 18. Alternatively, the trader data may be stored atthe central processing center 12 so that the trader does not need tore-build his/her screens each time he/she longs onto the system 10.

[0119] Thus, each trader workstations 20 at a client site 14 is able toaccess the system 10 through the Internet browser program 72 operatingon the user's desktop computer. In order to access the system 10, theuser may run Java-based applets on the desktop computer in the Internetbrowser program 72 which may be up-loaded to the desktop computer systemby one of three means: 1) accessing them from the hard disk of thedesktop computer 2) downloading them across the network from a server onthe internal data network of the client site, or 3) by downloading themdirectly from the central processing center. Once the applets are loadedand running in the desktop computer of the user, the user is then ableto access the system 10 and interact with other trader workstations 20and engage in trading activities. In addition to traders at the clientsites, a preferred embodiment of the present invention also enablesnon-trader users at the client sites 14, such as credit officers andother interested/relevant staff, to have access to the invention in thesame manner as the users in order to monitor the trading activities,perform credit control or any other functions.

[0120] III. System Features

[0121] The following are features of the present invention which provideparticular functionalities and utilities. These features includeinterfaces such as a command center interface, a market entry interface,a market details interface, an outstanding order interface, anhistorical order interface, and functions such as symbology, creditpreference checking, term negotiation, automatic notification, interestrate reset risk switches, and order auction.

[0122] When beginning a session on the system 10, a user at a traderworkstation 20 launches the Internet browser program 72 and goes to aparticular address that connects the trader workstation 20 to thecentral processing center 12. This is preferably achieved by typing aknown URL (Universal Resource Locator) in an address field of theInternet browser program 72. At the URL entered, the user will bepresented with a log-on screen which preferably requires the user toinput a user name and password for identification, verification andsecurity reasons. After the user logs on, the user will download(preferably from proxy agent 110) the Java applets which will runlocally on the desktop computer comprising the trader workstation 20.Alternatively, the user may launch a local or network application thatruns locally or on an attached server. The application will enable aconnection to system 10 over network 16, much the same as numerousdial-up services such as AOL. In addition, other information such asuser defined preferences which are based on the trader's profile will bedownloaded to the trader workstation 20. This may include information onwhat the user is allowed to trade, what markets the user is interestedin monitoring, and other user specific information that was previouslybeen defined by the user or another individual such a credit officer orthe like.

[0123] After the user has successfully logged on and the requisite Javaapplets have been downloaded and are running on the JVM 73, the user ispresented with a command center interface 130, as illustrated in FIG. 5,via the screen display device 88 (FIG. 3). The command center interface130 is the front end of the user interface which provides access to allother features of the present invention, as described below. In anembodiment of the command center interface 130, the command centerinterface 130 is a pop-up window rendered on the screen display device88. Note, however, when the command center interface is running, theuser may be able to iconize (i.e., minimize) the Internet browserprogram 72 window, as may be desirable when the user no longer needs toview the Internet browser program 72.

[0124] From the command center interface 130, a user can access thefeatures of the system 10 which enable the user to monitor and controltheir trading in the system 10. Specifically, from the command centerinterface 130 the user can access the following areas of functionalityas menu options on the tool bar 132: a market entry interface (describedbelow with reference to FIG. 12), a credit settings interface (describedbelow with reference to FIG. 10), a switch engine interface (describedbelow with reference to FIG. 22), auction interface (See FIG. 13),tools, a user preference interface (described below with reference toFIGS. 6A and 6B), an historical order blotter interface (described belowwith reference to FIG. 17), an outstanding order blotter interface(described below with reference to FIG. 16), links to externalapplications such as MarketSheet™ (a trademark of TIBCO, Inc.) (referredto herein as the quote screen and graph screen for illustrativepurposes), a logout interface (provides secure exit from the system 10),and a help interface where detailed on-line help is provided. The menuoptions that appear in the tool bar 132 are preferably customizable to auser, and those described are merely illustrative.

[0125] In addition, the command center interface 130 provides a messagedisplay window 134 for displaying real-time messages. These messagesinclude system information, market information, requests-for-prices(RFPs), requests-for-switch (RFS) or online chat sessions with the usersof the system 10. Below the message display window 134, the commandcenter interface 130 displays the user's name 136, the user's defaultcurrency 138, the user's business unit 140, and other relevantinformation. The background color of the message display windowpreferably changes if the connection to the central processing center 12is lost for any reason.

[0126] A user preferences interface 148, which is accessible from thecommand center interface 130 via the tool bar 132, provides a user withuser preference features, such as those illustrated in FIGS. 6A and 6B.In FIG. 6A, a Derv Filters tab enables a user to set request-for-price(RFP) filters for viewing different derivative instruments based on thetype (i.e., class) of derivative instruments and the currency. The usermay also select the manner of presentation (i.e., highlighted or not).From the Derv Filters tab, the user is able to add and remove thederivative instruments from the user's viewing list, that is, the listof instrument that will appear on the message display window 134 of thecommand center interface 130. In FIG. 6B, an Environment tab enables auser to select viewing options to change the appearance of the display.In regard to the color coding display option, it is noted that the usercan select not to have order information color coded by selecting colorblind user. In such a case, other means of notation are utilized such asmarkings or symbols, as may be desirable if the user is color blind orusing a monochrome screen display device 88. User defaults for CreditGroup, Instrument Class and SWF Currency may also be selected via theenvironment tab.

[0127] At this point, it is worth noting several functionalities thatare integral to the operation of the present invention. In particular,it was recognized that in order to achieve an electronic trading systemfor a wide range of financial contracts, a solution had to be developedto solve two very critical problems: (1) how to identify financialcontracts, and (2) how to allow institutions to describe their creditpreferences or relationships for these instruments. As solutions tothese problems, the present invention provides the symbology and creditpreference features described below.

[0128] The symbology of the present invention was developed because,unlike foreign currency trading, where the financial instruments aresimple, verbally explaining all the terms and conditions of a derivativetransactions can be a laboriously complex process which can take arelatively long period of time to explain. Furthermore, most derivativetransactions are specifically customized to fit a particular need. Withderivatives, as compared to stocks, bonds or other financialinstruments, there are typically many more parameters, such as thematurity, fixed interest rate, floating interest rate, currency,floating rate index, and calculation rates, which are important and arepreferably defined. This complexity has allegedly been one of majorinhibitors to the development and implementation of an efficientinter-dealer electronic trading system for over-the-counter (OTC)derivatives.

[0129] The symbology will, among other things, ensure that the symbolsare intuitive to the trading community, allow new symbols to be systemgenerated when new instruments are introduced, and enable detailedconfirmations to be prepared. These goals are generally accomplished bysystematically dividing the parameters, terms, and conditions definingthese derivatives instruments into a four-part subject code. Thisfour-part subject code enables the users to reference these instrumentsvia a form known as subject-based addressing. The four-part subject codeis divided as follows: SOURCE.CLASS.SYMBOL.CURRENCY. Each field of thefour-part subject code is defined below.

[0130] The source field of the symbology identifies the source of theinformation. In most cases, this will be the code DNI (i.e., DerivativesNet, Inc.), the assignee of the present invention. If the symbol is usedwithin the system 10, then the source field of the symbology will beassumed to be DNI, and will be omitted. If the symbol is used in alarger context, then the source will be identified. If, for exampletrade data were to be distributed and accessed via a third-party datadistribution system such as the type operated by Reuters, Inc., then thesource field of the subject code would be used.

[0131] The class field identifies the principal product class into whichthe financial instrument falls. The class parameter is designed to groupfinancial contracts together which share similar attributes. Forpurposes of the present disclosure, eleven classes of instruments, eachwith distinct characteristics covering forward rate agreements, interestrate swaps, interest rate basis swaps, interest rate options, foreignexchange and switches, will be covered. It is noted that a switch is thesimultaneous purchase and sale of two instruments within the same class.The following is a listing of the eleven classes and the associatedabbreviation for each:

[0132] FRA—forward rate agreement

[0133] SWP—interest rate swap

[0134] CAP—interest rate option (cap or floor)

[0135] SOP—interest rate option (swaption)

[0136] IBS—interest rate basis swap (floating vs. floating swap)

[0137] SPT—foreign exchange spot

[0138] FWD—foreign exchange outright forward

[0139] FXS—foreign exchange swap

[0140] SWF—FRA switch

[0141] SWT—switch any other pair of instruments in the same class

[0142] CBS—currenby basis swap

[0143] The symbol field is the principal code used to define eachinstrument. The symbol field is the most explicit field of the subjectcode. This component of the naming convention enables the underlyingstructure of the derivative instrument to be defined. A simpledescription (e.g., lyrswap) could be used, but this does not allow newderivative instruments to be easily added. The legend below defines theparameters for defining each of the different instruments or classes.The symbol relies on the definitions of the underlying parameters, whichwill allow further break down or definition. For example, FLOPT is a twoletter code which describes the variable rate index to be used, and willinclude: the designated maturity, index name, source, non-business dayconvention and calculation description. The symbols of the presentembodiment are as follows:

[0144] FRA: [START, END, OVER, FLOPT]

[0145] SWP: [START, END, OVER, FXDBASIS, FLOPT, SPECIAL RULE]

[0146] CAP: [START, END, OVER, FLOPT, TYPE, STRIKE]

[0147] SOP: [START, OVER, UNDERLYING SWAP, SOPTYPE, STRIKE, OPTTYPE]

[0148] IBS: [START, END, OVER, INDEX1, INDEX2, ARREAR]

[0149] SPT: [CCY1(terms), CCY2(base)]

[0150] FWD: [CCY1(terms), CCY2(base), START, END, OVER]

[0151] FXS: [CCY1(terms), CCY2(base), START, END, OVER]

[0152] SWF: [FLOPT, DAY1 , DAY2]

[0153] SWT: [ASSET1, ASSET 2, CLASS]

[0154] CBS: [START, END, OVER, INDEX1/CCY1, INDEX2/CCY2]

[0155] The symbol fields set forth above include the followingparameters:

[0156] START: The START parameter is the month the contract commencesoffset from value date, i.e., 1, 2, 3, . . . , 13, . . . , 360. Thedefault setting for the START is (0) which represents that a contractstarting with the current month. Also, see OVER below.

[0157] END: The END parameter is the final maturity from value date inmonths adjusted for the OVER, and represents the term, i.e., 1, 2, 3, .. . , 13, . . . , 360. If the value date is 28th of November, then acontract defined as [1, 4 over the 12th] translates into a deal startingon the 12th of January and maturing on 12th of April.

[0158] OVER: The OVER parameter represents a specific date in theappropriate month. For example, if today is the 3rd December (value dateis the 5th of December), then a 1*4 over the 12th would start the 12thof January, the first date over one month but less than two monthsbeyond the spot date. This allows a contract to be defined with anystart date between days 1-31. Note that this represents the actual dateand not the number of days forward. The default setting for the OVER is(0), which represents spot starting. Two other parameters are allowable:(I) which represents IMM (International Monetary Exchange) rolls (thesystem 10 covers the different IMM conventions defined by the currencymarket, that is, the third Wednesday or second Thursday) and (E) whichrepresents rolls over the month-end.

[0159] FXD BASIS: The FXD BASIS parameter is a two-part code coveringthe frequency and the basis of the fixed coupons. Examples are FREQ:M=Monthly, Q=Quarterly, S=Semi-annually, A=Annually, Z=Zero Coupon plusBASIS F=A/365 Fixed, B=30/360, M=A/360, I=A/365 ISDA, etc. For instance,SM is semi-annual A/360 or semi-money].

[0160] FLOPT: The FLOPT parameter is a two-part code covering thefrequency and the index type of the floating coupons, and represents thefloating rate option as defined by ISDA. The FLOPT parameter coversfrequency, basis and source. Although each currency may have a default,most indices will be available. FLOPT examples are L=Libor (TELERATE3740/50), P=Pibor (TELERATE 20071), T=Tibor, C=CDOR, B=AUS Bills(REUTERS BBSW), FF=Fed Funds (H15), TB=T-bills (H15), PR=Prime (H15),CP=30 day Commercial Paper, BE=BELO, S=STIBOR, TA=TAM, A=AIBOR, D=CIBOR(REUTERS DKNK), RL=Libor from Reuters LIBO, and IL=Libor from ReutersISDA.

[0161] CAPTYPE: The CAPTYPE parameter includes definitions for cap (C)and the floor (F). Thus, in a preferred embodiment, the following codeis utilized: C=Cap, F=Floor.

[0162] SOPTYPE: The SOPTYPE parameter includes definitions for payers(P) and receivers (R). Thus, in a preferred embodiment, the followingcode is utilized: P=Payers, R=Receivers, X=Call, Y=Pat.

[0163] OPTYPE: The OPTYPE parameter is the option type: (E)uropean,(A)merican or (M)ultiple European.

[0164] STRIKE: The STRIKE parameter indicates the cap or swaption'sexercise rate or price set on the option. Any strike defined in thesymbol as ATM (at-the-money) will be shown as such in this parameter. Insuch a case, the percentage or strike will be agreed through the termnegotiated process discussed below.

[0165] SPECIAL RULE: The SPECIAL RULE parameter is designed forcurrencies such as USD and CAD which are in particular markets that usefew special conventions for trading. For example, semi-bond for spreadtrades and annual money for out-right swaps are widely used in thesemarkets. The SPECIAL RULE parameter allows the system 10 to set morethan one set of defaults for any currency. This will allow the system 10to know when the exchange of bonds is required following a transaction.The follow are the rules for the present embodiment:

[0166] A—Default in all currencies

[0167] S—USD spread trades. The default in USD is annual money versus 3month LIBOR. This rule defines semi-bond spread trades where bonds areexchanged in the terms negotiation function described below.

[0168] 2—CAD spread trades. The default in CAD is annual money (A/365fixed) versus 3 month CDOR paid semi-annually. This rule definessemi-annual A/365 fixed versus 3 month CDOR paid semi-annually wherebonds are exchanged in the terms negotiation function described below.

[0169] 3—AUD long trades. The default for AUD is a quarterly/quarterlystructure. This applies for trades up to and including three years. Intrades over three years, the convention switches to a semi/semistructure. This rule supports a semi/semi structure.

[0170] 4—AUD spread trades. Its is conventional to trade swaps in theAUD market against the bond futures contracts with an agreement for anexchange for physical.

[0171] 5—GBP spread trades. The default in GBP is annual money (A/365fixed) versus 6 month LIBOR. This rule defines semi-annual A/365 fixedversus 6 month LIBOR where bonds are exchanged in the terms negotiationfunction described below.

[0172] ARREAR: The ARREAR parameter defines when the coupon(s) on a swapis both set and paid. Most interest rate swaps set their floating ratecoupons at the beginning of the period and pay them at the end of acoupon period. In an ARREAR swap, however, the coupon is set and paid atthe end of the period. This is commonly referred to as an arrears swap.The system 10 allows for this in the form of a basis swap.

[0173] DAY1/2: The DAY1/2 parameter is the number of calendar daysoffset from today to the start of each FRA in an FRA switch (class SWF).Thus, the DAY1/2 parameter represents the setting day or date.

[0174] CCY1/2: The CCY1/2 parameter is the currency code and is definedby the ISO codes for foreign exchange instruments.

[0175] UNDERLYING SWAP: The UNDERLYING SWAP parameter is the fullsymbol, alais or security ID of the interest rate swap that underlies anoption.

[0176] INDEX1/2: Basis Swaps are when both sides are a floating rate,and the index represents the FLOPT plus the currency code of each index.The first listed index (INDEX1) is paid by the buyer. Examples includeIL-USD, 3L-GBP, PR-USD, etc. The second index (NDEX2) is received by thebuyer. These are substantially identical to the codes used in the switchmechanism 35 (FIG. 2). For currency basis swaps, it is assumed that anexchange of principals takes place at the start and end on the contract.

[0177] ASSET1/2: The class SWT is provided to allow for the trading ofswitches in other classes other than FRAs. ASSET1 and ASSET2 representthe symbol, alias or security I.D. of each underlying contract. Notethat both should be provided from the same class of contracts.

[0178] SETTLE: The SETTLE parameter is a flag indicating whether aswaption is cash or physical settlement. The default is cash (C).

[0179] An example of an order in accordance with the symbology of thepresent invention is DNI.FRA.1,4.0,3L.USD, where DNI is the source, FRAis the class, .1,4.0,3L is the symbol and USD is the currency. Inparticular, the symbol field defines a 1 by 4 (i.e., 3 month starting in1 month) FRA on a 3 month LIBOR spot starting. Note that a comma (,) isused in the symbol fields as a delimiter. Another example of an order inaccordance with the symbology of the present invention isDNI.SWP.0,60,0,AB,6LA.DEM, where DNI is the source, SWP is the class,0,60,0,AB,6LA is the symbol and DEM is the currency. In particular, thesymbol field defines a five year (60 month) annual bond (AB) versus a 6month LIBOR swap.

[0180] Accordingly, the Symbology described above is designed to capturethe parameters or commercial terms of a derivatives instrument whichaffect the instrument's valuation. The present invention provides anumber of default values which are assumed at all times. For example,the following is an exemplary list of system default values.

[0181] ROUNDING: The rates observed on the source page or document willbe used unless otherwise agreed. Rates should be rounded to 5 decimalplaces after any operation of averaging.

[0182] RESET DATES: This will be defined with reference to paymentdates. The reset dates should be offset by the standard number of daysfor the currency, for example, two business days for USD.

[0183] BUSINESS CENTERS TO APPLY TO RESET DAYS: The business days usedto define the current offset for reset dates is defined by the sourceand not the payments under the transaction. For example, London willalways be used for LIBOR (the exception is for USD LIBOR which uses bothLondon and New York City) and New York City for H.15 rates.

[0184] INTERPOLATION: Where interpolation is required, a straight-linemethod using the reference rates on either side of the desired dateshould be used.

[0185] CALCULATION PERIODS: First and not last convention. Therefore,the calculation period includes the first payment date but excludes thenext payment date.

[0186] TERMINATION DATE: All termination dates will be subject toadjustment if they fall on a non-business day.

[0187] ADJUST CALCULATION PERIOD: The number of days is assumed toadjust if the payment days are adjusted for non-business days.

[0188] TRADE DAY: The trade day is defined relative to the instrumentand currency by the system 10, and not by the location of either of theparties to the transaction.

[0189] NET PAYMENTS: Net payments will be assumed for all transactionscompleted through the system 10.

[0190] CANADIAN DOLLAR SWAPS: The convention is to set quarterly and paysemi-annually using weighted averaging and compounding at the firstrate.

[0191] DATES: All dates are listed unadjusted for non-business days.

[0192] Users may also want to be able to negotiate other parameterswhich do not affect the valuation of the derivative instrument, but arestill very important. These parameters are referred to hereinafter asnon-commercial terms. The difference between commercial andnon-commercial terms can be vary ambiguous, and therefore, some of theterms designated as commercial below may be designated as non-commercialand become default settings so as to be part of the symbology parameter.For purposes of illustrating the present invention, non-commercial termshave been given default values which the users can change by negotiatingnew values for these terms between themselves via the system 10.However, both counterparties (users) must agree on the new value toover-ride the system defaults. Table 1 below provides a list ofparameters that maybe negotiated, that is, the non-commercial terms:TABLE 1 PARAMETER DESCRIPTION SETTING Legal The format of the legalagreement used ISDA, BBA, FX Month-end Whether coupon payment dates rollon YES, NO month-end dates or not Settle For swaptions whether thecontract is CASH, PHYSICAL cash or physically settled First Setting Forswaps the first variable rate is SETTING displayed on normally known forspot starting market entry interface. instruments. The current settingcan quickly become off market on days where the market movessubstantially. The system will display the default at all time. ATM Foroptions, symbols will be set up The system forward rate where the strikeis defined as at-the- will be available money (note: pre-defined strikeswill also be available). The actual strike will be negotiatedimmediately following the transaction by the two parties. Spot Forforeign exchange swaps (class FXS The system mid spot only) where theprice is transacted in price will be available the form of points, thespot level to be used will be negotiated immediately following atransaction. Base Switches will be transacted in the form The system midprice of the relative price between the two will be availableinstruments being switched. The base rate maybe negotiated immediatelyfollowing a transaction. Bond Exchange For USD, CAD and GBP interestrate The system will list the swaps transacted as a spread, the pricebenchmark bonds to be and number of bonds will be negotiated used andwill calculate a immediately following the transaction default price andnumber according to market convention.

[0193] Because the above symbols that comprise the subject-basedaddressing may be complex, users may occasionally desire a simplernaming convention to reference the more commonly traded derivativeinstruments. To facilitate more rapid referencing of an instrument by auser, the symbology of the present invention provides aliases. An aliasis merely an abbreviated version of the subject-based address for themore commonly used terms for an instrument. The database 66 (FIG. 2)maintains a unique security identifier (such as a numeric code, e.g.,111222) for each symbol which can be used in the system 10. Thus, thesymbology of the present invention enable traders and other users of thesystem 10 to quickly reference a particular derivative instrument in thesystem 10 in three ways: the fill symbol, the alias, and the identifier.

[0194] The currency field of the symbology contains the code thatdefines the currency of the instrument represented. In a preferredembodiment, the currency code is represented by the standard ISOcurrency codes, i.e., USD, DEM, JPY, GBP, FRF, NLG, BEF, AUD, CAD, ITL,ESP, DKK, SEK, EUR, etc. The default currency will be set by each userin each user's preferences interface 143 (see FIG. 6B). This will allowthe currency code field of the symbology to be omitted much of the time.However, foreign exchange trades (FXS) preferably include the currencycode. Further, the currency code represents the currency which will beindexed in equal amounts for both the spot and forward coupons.

[0195] The credit preference feature of the present invention providesfor the bilateral credit status between two entities to be captured,structured and used anonymously for the trading of a wide range offinancial contracts. In prior art systems, credit information wasprimarily used to deal with settlement risk in trading spot foreigncurrency. In such prior art systems, the credit line or limit is usuallyexpressed in amounts of currency which equates with the quantity orvolume of a particular trade. As trades are executed betweencounterparties, the amount of the limit is decreased in a correspondingamount to the trade executed until there is little or no remainingcredit, and then further trading is prevented until the trades settle orthe credit limit amount is re-set. In foreign currency trading, thesettlement process is completed in only a few days, after which bothcounterparties have exchanged the currencies, and then there is nofurther credit risk between them (i.e., the trades have settled). Thisis vastly different from derivatives trading, where the amount at riskis normally not equal to the principal or quantity of the transactionand the obligations under the contract may continue into the future.Derivative trades can be anything from spot (the normal settlement of aforeign exchange contract) to thirty years into the future Therefore,the resulting credit exposure (i.e., the value of a contract at a futuretime) is over the life of a contract of an unknown amount.

[0196] The credit preference feature of the present invention isconfigured to handle the significant long-term credit problems inherentin over-the-counter (OTC) derivatives transactions. These long-termcredit problems are further compounded by the fact that there is nostandard method for banks to internally monitor and manage their creditrisks. Most banks have developed their own, often proprietary, methodsof monitoring and measuring the credit risk embedded in large portfoliosof derivatives. Furthermore, banks also have different methods fordealing with the many different financial instruments that exist inevery market.

[0197] The credit preference feature of the present invention addressesthese problems and provides a viable solution. The credit preferencefeature of the present invention achieves this, at least in part, byintroducing a measurement unit of credit risk referred to as riskequivalent (RQ) which allows for different instruments to be compared ona like basis using a standardized measuring methodology, which togetherwith the concepts of contract maturity, credit groups, classes, creditpreferences, legal entities and business units allow the system 10 tooffer a solution to the credit risks embedded in bilateral, termderivatives contracts. The present invention also provides for thedesignation of credit groups. A credit group is a grouping of classes offinancial contracts that a business unit wishes to be treated in a likemanner for credit purposes. In a preferred embodiment, three defaultcredit groups will be available: (1) Derivatives—SWP, IBS, CAP, SOP,FRA, CBS; (2) Switches—SWT, SWF; and (3) foreign exchange. Any othercombination may be set up by the business unit, as desired.

[0198] Credit preferences are the methods or rules selected by abusiness unit within a credit group for the system 10 to use to screenprices (bids or offers) and trades against all other legal entities. Ina preferred embodiment, the following three credit preferences areprovided, though it will be appreciated by those of ordinary skill inthe art that other credit preferences may be utilized in accordance withthe present invention:

[0199] Method 1: Binary (simple yes/no)—This is used wheremark-to-market (MTM) agreements exist between the counterparties. MTMare bilateral, collateral agreements which are common and reduce thecredit risk between two parties to ahnost zero by the posting ofcollateral against the value of a portfolio of derivatives covered by asingle ISDA (International Swap and Derivatives Association) masteragreement.

[0200] Method 2: Line Binary—takes into account the maturity (quoted inmonths from trade date) of the financial contract.

[0201] Method 3: Complex—This is based on the RQ of each contract withinmaturity bands. The system calculates a RQ for each instrument in theform of a constant currency unit expressed as a percentage. Eachbusiness unit has the choice of using the system generated RQ unit or toprovide their own.

[0202] In the binary method, a business unit makes a yes or nodetermination as to whether or not they will deal with a particularcounterparty for a particular credit group. In this credit preference,the decision is binary; there is no maximum maturity limit (i.e., timelimit) or quantity limit (i.e., amount) in the binary method. The binarymethod is the broadest of the three credit preference definitionsprovided for herein. Typically, the binary method will be used to refusecredit, where MTM agreements exist or where the credit exposure is small(for example, in switches).

[0203] In the line binary method, it is assumed that the business unitwill deal with a particular counterparty for a particular credit group.However, the line binary method adds a further restriction of a maximummaturity of any contract tradable. The added restriction is preferablyexpressed by the number of months into the future. The binary method isparticularly well suited for used by institutions that are not yet usingRQ units, but which desire a method to limit potential exposure tolonger dated contracts (for example, a temporary step).

[0204] The complex method allows each business unit to exactly stipulatethe amount of new risk that they are prepared to enter into with anyother legal entity for each credit group by maturity band. The complexmethod enables a business unit to specify not only a particularmaturity, but also a particular quantity or amount based on a measure ofRQ. Further, the complex method enables the business unit to specifythis for more than one period in time. For example, a business unit canspecify that for Bank A, they will do up to $100 million out for 5years, and then only $50 million from thereafter out to 10 years, andnothing thereafter.

[0205] Risk is generally defined herein as the degree of uncertainty offuture net returns. Credit risk is further defined as an estimate of thepotential loss due to the inability of a counterparty to meet itsobligations. Thus, while the risk in a particular transaction dependsnot only on the changes in market rates and credit standing of thecounterparty to the transaction, the credit risk or exposure is thenominal amount that can be lost when a counterparty defaults on itsobligation. As previously mentioned, the credit risk in a derivativestransaction is relatively complex. For instance, though derivativecontracts come in many forms, the majority have a fair credit value ofzero at the time the transaction is initially entered into. That is, nofunds are transferred between the parties at the time the contract iscreated. Rather, the contract places an obligation on both over the termof the contract. Further, both parties are entering into a contractwhich requires them to accept a certain amount of risk. The RQ is a unitof credit risk which allows all contracts to be compared on a likebasis, at virtually any point in time. The RQ is the credit exposure interms of a percentage of the principal.

[0206] The calculation of RQ is based on the potential exposure averagedover a series of time points, weighed by an appropriate discount factor.There are several methods of calculating the exposure of a transaction,though the RQ is calculated herein using an option pricing approach, asdescribed below.

[0207] For a certain party, a transaction can be viewed as two oppositecash flows. Inflows are assets, denoted by A(t), and outflows areliabilities, denoted by L(t). Therefore, the current exposure may beexpressed as follows:

E(t)=max(A(t)−L(t),0)

[0208] This formula is similar to the intrinsic value of a call option.The key difference is that both A(t) and L(t) can be random. Thus,following the same structure by the Black-Scholes, then:

EE(t)=Aφ(d ₁)−L(t)φ(d ₂),

[0209] where

[0210]d ₂ =d ₁−σ(t){square root}{square root over (τ(t))}$d_{1} = \frac{{\log \left( {{A(t)}/{L(t)}} \right)} + {\frac{\sigma^{2}(t)}{2}{\tau (t)}}}{{\sigma (t)}\sqrt{\tau (t)}}$

[0211] where σ(t) is the daily volatility (in percent) that takes intoaccount that both A(t) and L(t) are random. The maximum exposureestimate is based on the following equation:${{ME}(t)} = {{A(t)} - {L(t)} + {{A(t)}\left\lbrack {e^{1.65{\sigma {(t)}}\sqrt{\tau {(t)}}\frac{\sigma^{2}{(t)}}{2}{r{(t)}}} - 1} \right\rbrack}}$

[0212] Thus, the RQ can be expressed as:${RQ} = {\frac{{AEE}(t)}{Principal}*100\% \quad {where}}$${{AEE}(t)} = {\sum\limits_{i = 0}^{N}{{\omega (t)}{E\left\lbrack {E(t)} \right\rbrack}\quad {where}}}$${\omega (t)} = \frac{\delta (t)}{\overset{N}{\sum\limits_{0}}{\delta (t)}}$

[0213] where δ(t) is the discount factor at future time t.

[0214] For FRA's, the following equations apply:

A(t)=*discountFactor(t,s)*x+(1+floatingCoupon) *discountfactor(t e)

[0215] where

floatCoupon=1*(e−s)/floatBasis*floatRate, and

L(t)=1*discountFactor(t,s)*x+(1+fixCoupon)*discountfactor(t,e)

[0216] where

fixCoupon=1*(e−s)/fixBasis*fixRate,

[0217] for t<s, x=1, and for t>=s, x=0.

[0218] Then we can apply the above formula for RQ to get the expectedexposure at time t. By choosing the time partition t0, t1, t2 . . ., tnand calculate the expected exposure at each point and use the formulaeof RQ, the RQ of this FRA can be calculated.

[0219] For SWAP's, the following equations apply for any time(t_(i)<t<=t_(i+1)): ${{A(t)} = \sum\limits_{j = i}^{n}}\quad$

 floatingCoupon(t _(j))*discountFactor(t,t _(j))+1*discountFactor(t,t_(n)), and ${L(t)} = \sum\limits_{j = i}^{n}$

 fixedCoupon(t _(j))*discountFactor(t,t _(j))+1*discountFactor(t,t_(n)),

[0220] where floatingCoupon(t_(j)) is the floating coupon at time t_(j),and fixedCoupon(t_(j)) is the fixed coupon at time t_(j). Then apply theformulae of option pricing approach, we can get the expected exposure attime t, by averaging the expected exposure with the discount factor, theRQ can be calculated.

[0221] At this point it may be worthwhile to distinguish the creditpreference feature of the present invention from other known systems.The credit preference of the present invention does much more thanmerely monitor the amount transacted between two counterparties and thenreduce the amount available accordingly. The prescreening performed bythe credit preference of the present invention is used to prescreenpossible trades based on each counterparty's credit preferences. Thepresent invention does not control a user trading and does not directlylimit the user's future trading based upon the user's past trading. Infact, it is quite possible that a new transaction may reduce theexposure between two legal entities. A user's business unit isresponsible for monitoring the credit exposure of the business unit withrespect to all legal entity counterparties, and for adjusting the creditpreferences in the system 10 accordingly. This is a significantdifference from prior art systems that automatically decrease the amountavailable to trade with respective counterparty as transactions areexecuted. The credit preference of the present invention represents animprovement over such systems because the balance of risk is based onthe total portfolio between the two parties and not merely the newtransactions, and the balance of risk will be affected by marketmovements, deals executed outside the system 10, and internal changes tothe ratings.

[0222] Credit decisions for OTC derivatives are considered differentfrom many other financial instruments. In general, a credit decision foran OTC derivative is a function of, among other things, the compositionof the user's current derivatives portfolio, the current level or pricesof the financial markets, new financial transactions, and the rating orlevel of credit worthiness of each legal entity. Therefore, moresophisticated means such as the credit preference prescreening of thepresent invention is needed to adequately measure and manage creditexposure in the OTC derivatives market, as well as with other financialmarkets.

[0223] The present invention enables the user to set desired creditpreferences for each legal entity via the credit preference interface170, as illustrated in FIG. 7. A user can navigate to the creditpreference interface 170 by selecting the credit settings button in thetool bar 132 of the command center interface 130 (FIG. 5). The creditpreference interface 170 enables the users to view and/or update creditpreference settings in a clear, simple, comprehensive and intuitivemanner. The credit preference interface 170 may be used to view orinput/amend the business unit's credit preferences. The creditpreference settings are preferably only viewable by users within abusiness unit, and amendable by users with the correct permissions, bothof which may be designated by the financial institution or the businessunit. A business unit may also select to inherit credit preferences fromanother business unit within its family hierarchy.

[0224] In a preferred embodiment, the credit preference interface 170includes a display window 172 that displays various informationincluding an alphabetical listing of all other legal entities (i.e.,financial institutions) that have access to the system 10. Each legalentity can be expanded via an expand button 174 to list the settings forall the credit groups that the user has selected to trade within thatlegal entity, as shown for the Merrill Lynch entry. For those legalentities that are not expanded in window 172, the settings displayed arefor a designated default credit group 176. The user can modify thedisplayed credit groups by selecting the Modify Credit Groups button 178which launches the modify credit group interface 180, as illustrated inFIGS. 8A and 8B. The modify credit group interface 180 enables the userto customize his/her class groups by providing functionality to performsuch operations as adding and removing instruments from a class group,as illustrated in FIG. 8A. For instance, for a selected credit group182, a list 183 of instruments in that credit group is provided.Unassigned instruments can be added and member instruments can beremoved. Further, credit groups 182 can be added and deleted via buttons182, 185, respectively. In FIG. 8B, each credit group 182 may have bandsof maturity 186 defined (i.e., added or deleted). Each class grouppreferably includes instruments that are closely related because theinstruments in each class group are given the same credit preferencesetting, and therefore, the credit preference setting process may besimplified.

[0225] Referring back to the credit preference interface 170 of FIG. 7,a preference setting column 187 provides the credit preference settingdesignated for the corresponding legal entity 183. The credit preferencesettings for any legal entity can be modified or selected via adrop-down dialog box 188. From the drop-down dialog box 188, the usercan select from a list of predefined credit preference option. For a newline binary, the user is prompted with a new line binary interface 189in which the user can enter a maturity. For complex, the user isprompted with a complex preference interface 190 (FIG. 9B) in which theuser can enter the exposure for each maturity band.

[0226] With reference back to FIG. 7, the complex credit preferencesettings and the RQ may be provided for each instruments designated assuch by selecting an appropriate legal entity and then selecting theComplex Bands button 194.

[0227] If the user does not set a particular preference for a particularcounterparty, then the credit preference will be assumed to be a simplebinary (no). If after initially setting these preferences a newcounterparty is added to the system, the preference for the newcounterparty will be binary (no) for all users until they havespecifically set a credit preference for the new counterparty.

[0228] The level column 196 displays the business unit's designation foreach legal entity as to the levels A, B or C. The level set for eachlegal entity may be provided by the system 10 via various interfacessuch as a market detail interface (described below with reference toFIG. 15) to provide the trader with information with regard to thecreditworthiness of the counterparty. Thus, a business unit may assignone of the levels A, B or C against each legal entity. This isessentially a quick reference of credit worthiness for the user.

[0229] The columns 198 labeled S&P and Moody are industry credit ratingsthat are integrated into the credit preference interface 170. Theindustry credit ratings may be downloaded on a subscription basis viaexternal communication interface link interface 62 (FIG. 2). Lastly, thelast modified column and the modified by column identify the time andperson that last modified that credit setting. As mentioned before,access to modify any of the credit preferences should be limited to afinance officer or credit officer of the legal entity.

[0230] It should be noted that the credit preference settings may betransferred via electron file transfer or inputted manually on-line atanytime, and as often as the user desires. Further, updates may be madefor all credit groups and legal entities, or alternatively, updates canbe just for individual settings.

[0231] In addition, the credit preferences interface 172 includes a BUInfo button 202 which, if selected, brings up a business unit datainterface 204, as illustrated in FIG. 10. The business unit datainterface 204 enables the users to view helpful internal informationabout other legal entities. The respective business units define whatinformation is included in the business unit data interface. Forexample, the business unit data interface 204 of FIG. 10 provides theinternal facility number, telephone number, internal reference number,internal net MTM, internal gross MTM, and internal number deals of abusiness unit. Alternatively, a business unit may include a contact nameor other business unit specific data.

[0232] Accordingly, the credit preference logic of the present inventioncan be illustrated graphically as shown in FIG. 11. For purposes of FIG.11, it is assumed that business unit (i) belongs to legal entity (i)where i=1, 2, and 3, and business unit (j) belongs to LE (j) where j=1,2, and 3. Accordingly, FIG. 11 illustrates a portion of the credit datawhich is stored by the system 10 in order to implement the creditpreference feature of the present invention. Each column represents thecredit preference (i.e., binary, line binary, or complex) which isstored anonymously for each business unit against each legal entityacross all credit groups. The vertical and horizontal bars 210 representthe information which business unit (3) requires to determine the creditpreference status of an order. The information in columns 210 providesthe credit preferences which business unit (3) has set against all otherlegal entity, and row 211 provides the credit preferences which allother business unit s have set against business unit (3)'s legal entity,that is, legal entity (3). The depth 216 of the graph is divided intothe different credit groups such as switch, derivative, and foreignexchange.

[0233] The triangles 212, 214 mark the cells that include theinformation which is used by business unit (3) to encode a specificorder from business unit (5) of legal entity (5) with credit statusinformation for presentation to the user via one or more of theinterfaces described herein. In a preferred embodiment, the creditpreference feature of the present invention color codes the creditpreference status of each order from the perspective of the viewingbusiness unit. Alternatively, another method of encoding the creditpreference status of an order may include adding a character notationsuch as an asterisk or star to an order, as may be desired if the useris color blind.

[0234] Each order is color coded according to the credit preferencesmarked by the triangle 212, which corresponds to what the order placer'sbusiness unit has set against business unit (3)'s legal entity, and thetriangle 214, which corresponds to what business unit (3) has setagainst the order placer's legal entity. The order is evaluatedaccording to the credit preference defined in the cells marked by thetriangles 212, 214, and the results can be displayed to the user via thecolor coding scheme set forth below where true means that the orderpasses the credit preference of the setting party and false means thatthe order does not pass the credit preference of the setting party:Triangle 212 Triangle 214 Color False False RED False True YELLOW TrueFalse RED True True GREEN

[0235] Thus, each order is color coded to communicate to the user thetradability of the bids and offers in the market based on thepreferences of both users. The color coding methodology described hereinis used in both the market entry interface (described below withreference to FIG. 12) and the market detail interface (described belowwith reference to FIG. 15). For the present embodiment of the invention,the following meanings are associated with the cited colors:

[0236] GREEN: The price passes the credit preferences of both parties,and the counterparties are free to trade. Any trade that is shown ingreen can be freely traded by the trader, and credit approval is assumedto be in place.

[0237] YELLOW: The price posted is free to trade by the viewer, but theposter of the price has excluded the viewer from his/her creditpreferences. If the price is colored yellow, a deal may be allowedprovided that the party who placed the passive order allows mutual puts,and the credit over-ride process which is described below is completed.The viewer can attempt to trade by sending a message (thereby initiatingthe credit over-ride process) to the poster of the price which disclosesthe name and/or identity of the viewer, along with a mutual put maturityentered by the viewer. The poster then has the opportunity to accept,accept subject to credit (in either case, the poster may also reduce thematurity of the mutual put), or decline. The poster's name will not bereleased to the viewer until a trade is executed. The posted price willremain available to all other traders on the system 10 until a trade iscompleted. If the order trades to another viewer, then the creditover-ride process will be terminated.

[0238] RED: The price posted is excluded by the viewer's own preferenceseven though the poster is (may be) clear to trade. In this situation,the viewer is not free to trade since it is the viewer's own creditpreference that the viewer set which is preventing the trade.

[0239] BLUE: The price is the viewer's own order.

[0240] WHITE: Only used in the market entry interface 250 (FIG. 12) todisplay prices where there are multiple orders at the best price withdiffering codes. Thus, the viewer is notified to view the market detailsinterface for more information.

[0241] In the over-ride process mentioned above, if the viewer sees aprice coded yellow that he/she wishes to trade, then the viewer mayactivate the over-ride process. The over-ride process begins byprompting the posting party with a request for an order quantity. Themessage sent to the poster essentially states that the viewer, which isidentified by name in the message, wishes to trade a stated quantity andthat the receiving party has a stated period of time to respond, forinstance, 15 seconds. The viewer will then see a copy of his/her messageand a clock which displays the countdown of the stated time to theposter. The poster receives the message and can decline or accept. Ifthe poster declines, then the viewer is informed accordingly. If theposter accepts, then the poster has the option to add a mutual putmaturity and request a small price adjustment, which will be stated in aspecified number of months. The viewer cannot back out of the tradewhile the clock is running (unless a price adjustment is requested).Further, at no time is the poster in a trade until all steps arecomplete.

[0242] The process by which passive orders are color coded is describedat this point. Regardless of the credit preference type, the traderworkstation 20 generates a maximum maturity value that determines how anorder will be color coded. The maximum maturity value is in the form ofan integer n digits in length, with the right-most two digitsrepresenting days, and the left (n−2) digits representing months.Therefore 12000 represents 10 years, 3600 represents 36 months, and 114represents 1 month, 14 days. The method by which credit preferences areconverted to a maximum maturity value is represented by Table 2 below.TABLE 2 Preference Type Maximum Maturity Binary No −2³¹, the smallestpossible integer value Binary Yes 2³²−1, the largest possible integervalue Line Binary The maximum maturity associated with the preference(e.g., Line Binary/12 has a max maturity of 1200) Complex The maturityof the highest band with an exposure amount greater than zero. (e.g.,The following complex preference would have a max maturity of 6000) MatBand Exposure 100 10,000,000 600 5,000,000 1200 3,000,000 3600 1,000,0006000 500,000 12000 0

[0243] Every instrument in the system 10 possesses a maximum maturityvalue. To determine whether a particular order can be traded, themaximum maturity for the order's instrument is compared to the maximummaturity of the credit preference. If the instrument's maximum maturityis greater than that of the credit preference, then the order may betraded, otherwise it cannot be traded.

[0244] Note that the maximum maturity assigned to a Binary-No preferencewill be lower than that of any instrument, effectively making allinstruments untradeable. Likewise, the maximum maturity of a Binary-Yespreference will exceed that of any instrument.

[0245] In order to determine the appropriate color code, the tradeworkstation 20 maintains two lists for each instrument class. One listincludes the credit preferences that the viewer has set against allother legal entities for that instrument class. This list may bereferred to as MY_PREFS. The other list includes the credit preferencesthat all other business units have set against the viewing legal entityfor that instrument class. This list may be referred to as OTHER_PREFS.Each of these lists contains the following data: Business Unit ID (Onlyused for OTHER_PREFS) Legal Entity ID (Only used for MY_PREFS) MaximumMaturity Credit Level (Only used for MY_PREFS)

[0246] Consider, for instance, an order for an arbitrary FRA instrumentplaced by business unit (1) of legal entity (1). When the order isbroadcast out to a plurality of traders 20 (i.e., viewers), the orderwill include the following information: Business unit of trader placingorder: business unit (1) Legal entity of trader placing order: legalentity (1) Maximum Maturity of order: 3600 (for example)

[0247] In order to color code the order, the viewing party must extractand utilize his/her credit preference against legal entity (1) from theFRA MY_PREFS list, and business unit (1)'s preference against him/herfrom the FRA OTHER_PREFS list. From the credit preferences extracted,the color of the order as it will appear to the trader is as defined inTable 3 below. TABLE 3 MY_PREFS OTHER_PREFS PREFERENCE PREFERENCE Colorof Order max maturity >= 3600 max maturity >= 3600 false false red falsetrue red true false yellow true true green

[0248] Also, note that the MY_PREFS list may contain a credit level(e.g., which may be associated with the order and presented to theviewer.

[0249] Accordingly, when the user logs into the system 10, the userpopulates the MY_PREFS and OTHER_PREFS lists for the instrument classesfor use by the credit preference module 76 (FIG. 3). This is achieved bythe central processing center 12 sending to A trader workstations 20that is logging-on one or more messages including the MY_PREFS andOTHER_PREFS lists from the database 66 on the hard disk 64 (FIG. 2).

[0250] When a user changes a credit preference assigned to a legalentity for a particular credit group in a way which causes the maximummaturity of the credit preference to change, the user will receiveupdates to MY_PREFS from the central processing center 12. Also, anyuser within the affected legal entity who is logged on to system 10 willreceive an update to OTHER_PREFS. Changes to complex preferences do notrequire such an update unless the zero band is changed (thus modifyingthe maximum maturity). If the user changes the credit level associatedwith a legal entity, the user will receive an update to MY_PREFS.

[0251] However, these two updates should not be performed at the timethe changes are made, as doing so could allow a user to determine thelegal entity that placed an order by methodically changing his/hercredit preferences against each legal entity from a green state to a redstate until the order changed color. Instead, the required updates willbe collected and sent out on an periodic basis. Also, to discouragediscovery of a counterparty's identity by assigning a unique creditlevel to a single legal entity, each credit level should be assigned toeither no legal entity, or to more than one legal entity.

[0252] From the command center interface 130, a user may enter themarket entry interface 250, as illustrated in FIG. 12. At the marketentry interface 250, the user can simultaneously monitor numerousmarkets and place orders, including bids and offers. The market entryinterface 250 also allows the trader to select any instrument(s) to bedisplayed, and multiple market entry interfaces 250 with various tradingfunctions (e.g., common FRA on one interface, SWAP on another interface,and Switches on yet another interface) may be opened on the trader'sdesktop simultaneously. The market entry interface 250 is designed topresent the sum of the best bid and ask, and the act of trading by anytwo parties by a flashing volume indicator in the top right-hand comer.Thus, the market entry interface 250 enables a trader to easily monitormany different markets with relative ease and utility. It should benoted that the system 10 does not perform auto-matching of orders, butallows the user to maintain control of the trading process at all times.The system 10 does this by introducing the concepts of active andpassive orders. A passive order is an order placed in the system 10 fora particular instrument, for a particular quantity, at a specific price,for a particular time period (see order types below). An active order iswhen a user decides to trade a passive order displayed in the system 10,and is usually only required to provide the quantity. Thus, there can beactive or passive bids and offers.

[0253] The user may customize the market entry interface 250 by addingand removing instruments (i.e., markets) displayed in the instrumentdisplay window 252. The user may add new markets by entering aninstrument symbol (according to the symbology of the present invention)into instrument identifier field 254. The user may also want to definegroups of instruments which can be saved as profiles and viewedtogether. Profiles allows the user to organize multiple markets by likeattributes. The profile being viewed is displayed in the profile displayfield 256. The profile display field 256 is a pull down menu that liststhe other profiles defined by the user. Until the user defines a firstprofile, the profile display field 256 is set to default.

[0254] Individual markets displayed in the instrument display window 252are divided into four columns: instrument, best bid, best ask, and info.The instrument column displays the instrument name (i.e., the symbol,alias or a security identifier). The best bid column displays the bestbid information, defined herein as the orders that are at the bestprice. The best bid information includes a relatively large centralnumber that displays the least two significant digits of the price, abottom left number that displays all but the least two significantdigits of the price, a bottom right number that displays any volume orquantity currently trading, and a top right number that displays thequantity of currency units in millions. Depending on the precisiondesired, a greater or lesser number of digits can be displayed as thelarger central number. The precision of the displayed central numbers isdefined for each instrument, and may, for example, include 2, 3, 4, ormore digits. The best ask column is substantially identical in format tothe best bid column, but displays the best asking price rather than thebest bid price. The info column provides space for data items that theuser may select to view, as defined in an info window 258. In thepresent embodiment, three items are defined in the info window 258, andthus, the corresponding information for the instrument will be listed inthe info column.

[0255] The system 10 provides users with a symbol construction interface270, as illustrated in FIG. 13, that can be accessed via a Lookup button272 from the market entry screen 250. The symbol construction interface270 functions to aid the user in selecting instrument for display in theinstrument display window 252. From the symbol construction interface270, the user can view available aliases in window 273, explode a symbol(i.e., view a list of underlying parameters associated with the symbol,for example, payment date) via the Explode Symbol button 274, selectsymbols to be added to a profile via the Add to Profile button 276, andconstruct new symbols or aliases via the Build Symbol button 278. Thesymbol construction interface 270 also provides error checking such thatonly valid symbols can be selected. An instrument should exist in thedatabase to be valid, and not all combinations will exist. Foradditional verification, the symbol explode function of the ExplodeSymbol button 274 enables essentially all aspects of the instrument tobe displayed in detail. Thus, the explode symbol feature provides acomplete detailed description of the instrument in Symbol window 280.

[0256] The symbol construction interface 270 screen also enables theuser to search for groups of symbols by at least partially filling outthe input parameters 282 located above a Search Options button 284, andthen selecting the Search Options button 284. The input parameters 282include various non-commercial terms of an instrument that can benegotiated following a transaction. For instance, as shown in FIG. 13,the input parameters 282 include class of instrument, currency, startmonth, end month, over, FLOPT, and special rules. By at least partiallyfilling in these parameters, the user can search for similar instrumentswhich are displayed in window 280.

[0257] Referring back to market entry interface of FIG. 12, it is notedthat the prices displayed in the best bid and best ask columns areencoded with credit information using the color scheme described above.As previously mentioned, color-blind users can have the color codingscheme replaced by a symbol scheme in which different symbols arepositioned next to the respective prices to indicate the credit statusof the order. The symbol scheme may be chosen by the user under theEnvironment tab of the preference interface 148 (see FIG. 6B).

[0258] It should also be noted that the inventors of the presentinvention are not presently aware of any electronic trading system thatoffers color-based credit preference pre-screening such as thatdisclosed herein. The present invention provides color-based creditpreference pre-screening because, unlike the prior art systems whichonly show the best dealable price or the best minimum quantity, thepresent invention shows all prices (bids and offers), irrespective oftheir credit preferences. Thus, the user can be provided with as wide ofa view of the markets as the user desires. Advantageously, the colorcoding enables the user to visually determine virtually instantaneouslywhat bids and offers are tradable based on the credit preferences of thetrader and the counterparty.

[0259] Once the user has entered the desired financial instruments inthe market entry interface 250 via the symbology, the best bid andoffers for each of the desired instruments will be displayed in theinstrument display window 252. The best bid and best offer pricesdisplay in window 252 are different from many prior art systems becausethey are the absolute best bid and best offer at the stated quantity.Because of the unique color coding scheme, the user is able to quicklytell whether or not the bid or offer is tradable by him/her. If the userso desires, the user can select a financial instrument with the pointingdevice 86 (FIG. 3), such as a mouse, so as to highlight the row in theinstrument display window 252 for that instrument. Once the financialinstrument is highlighted, the user may perform one of several functionsprovided for by the function bar 290, each of which is described below:

[0260] EXPL Function: This explodes the instrument symbol into a fulldescription of the contract, and mirrors the confirmation

[0261] HIT, LIFT, ORD Functions: These three buttons allow a user toselect an instrument and then place a new order, or execute an activeorder, by hitting or lifting the desired respective bid or offer. TheHIT, LIFT, ORD functions can also be carried out by double clicking themouse in the screen itself.

[0262] RFP Function: request-for-price messages are an important tool toallow the market to communicate. If a trader wishes to see a market, abroker will be contacted via the telephone, and the broker will in turnphone other traders to drum up interest. Using the system 10 of thepresent invention, the same result can be achieved instantaneously bysending an RFP to all registered users. This message may be displayed inthe command center interface 130 of other users, informing them of a RFPin the named instrument. In addition, because derivatives traders areoften trading more than one financial instrument, and sometimes in morethan one currency, derivatives traders will often have multiple passiveorders. The present invention provides at least three order managementfunctions to facilitate the canceling or temporarily suspending theorder. This may be an important functionality when the market is movingquickly, or if the position of a trader suddenly changes.

[0263] XLST Function: This function cancels the last passive orderplaced by the trader. Therefore, if a user submits an order andimmediately changes his or her mind, the order can be canceled withoutthe need to select the order individually.

[0264] XALL Function: This function allows the user to cancel all his orher outstanding passive orders in one key stroke.

[0265] REF Function: This function allows the user to suspend or placeall orders under reference. This is an alternative to canceling ordersone by one. For instance, if a user is expecting news that may affectonly a few outstanding orders, it may be safer to place all orders underreference, and individually re-release the orders the trader expects notto be affected back into the market.

[0266] DEL Function: This function allows the user to delete a marketfrom the profile.

[0267] In specific regard to the ORD button in the function bar 290, auser can submit a passive order by selecting the ORD button. If the ORDbutton is selected, a passive order interface 294 is provided to theuser, as illustrated in FIG. 14A. From the passive order interface 294,the user can place a passive order such as a bid (i.e., buy) or an ask(i.e., sell). The user enters a price, quantity, and selects how longthe order will be good. The price will default to current market levelso the user may only need to enter the last two digits of the price. Forquantity, the system 10 recognizes m, mm and b for thousands, millionsand billions, respectively. The system 10 allows the following ordertypes to be entered under the good until option:

[0268] good until logout (default)—Requires the user to be logged on andto monitor the orders status.

[0269] good until time—The user will be prompted to enter a time (in hisor her own time zone). This order does not require the user to be loggedon and will be canceled automatically by the system 10 at theappropriate time.

[0270] good until canceled—This order again does not require the user tobe logged on, but must be canceled by the user.

[0271] The system checks any new order for reasonableness (or training)as they are placed. For example, a bid cannot be higher than theexisting offer without the user double checking. The tab key, enter key,or the mouse can be used to navigate through the passive order interface294. Upon selecting the OK button, the order is submitted into thesystem 10 and the user is returned to the market entry interface 250.

[0272] In specific regard to the HIT and LIFT buttons in the functionbar 290, a user can initiate active orders by hitting a bid (i.e., sell)or lifting an ask (i.e., buy). By selecting either the HIT or LIFTbutton, a hit order window or a lift order window is presented to theuser. For example, a hit order window 296 is illustrated in FIG. 14B.The hit order window 296 is substantially identical to the lift orderwindow. As shown, the hit order window 296 identifies the instrument andorder price. Further, the user is presented with a transaction quantitywhich is initially set for the full amount being offered by thecounterparty. The user is allowed to reduce the quantity figure. Theuser is not allowed at this point to increase the quantity figurebecause the counterparty has already indicated the quantity they aredesiring to sell. Upon selecting the OK button, the order is executed bythe system in the manner described below, and the user is returned tothe market entry interface 250.

[0273] In addition to the above functions provided by the function bar290, if the user wants to see the full depth and breath of a particularmarket in a particular financial instrument, the user can select (e.g.,highlight) an instrument in the instrument display window 252 and thenclick on the MDS button 292. This will launch the market detailinterface 302, as illustrated in FIG. 15 for the highlighted instrument.

[0274] The market detail interface 302 enables a trader to viewessentially all the orders in the market for a particular instrument,both bids and offers. The bid orders are listed in a bid window 304where the credit levels (e.g., A, B or C), bid quantities and bid pricesare provided. The offer orders (i.e., ask orders) are listed in askwindow 306 where the ask prices, ask quantities and credit levels areprovided. As with the market entry interface 250, the orders arecolor-coded with the appropriate credit preferences. This is asignificant departure from many prior art systems which only show thebest dealable price or blended prices.

[0275] In the market detail interface 302, orders are individuallylisted in the bid window 304 or the ask window 306 in order of price,and then according to the time the orders were entered into the market.The user has the ability to select any order on the screen and hit orlift the order, assuming of course that the respective creditpreferences will permit a trade. The user is provided with a functionbar 308, which is substantially the same as function bar 290.Particularly, the buttons of the function bar 308 are substantiallyidentically to those on the function bar 290 except that they only applyto a particular instrument while the buttons of the function bar 290apply against multiple instruments. Further, a fair price indicator,spot/setting indicator (i.e., the LIBOR for that day), and last tradedprice indicator are provided along the bottom of the bid window 304 andask window 306. The last trade pricing may be replaced by volume,duration, RQ, last close price, etc.

[0276] An advantage of the market detail interface 302 is that the useris not restricted to trading only the best price or first order. At nopoint in the process will any orders be automatically matched againsteach other by the system 10. The user is in complete control of theorder flow process.

[0277] Thus, the user can execute both passive and active orders fromeither the market detail interface 302 or the market entry interface250. At either interface 250, 302, if the user wants to execute a trade,then the user only need to highlight the desired bid or offer and selectthe corresponding function button from the respective function bar 290,308 to initiate the transaction. Although the semantics of placing,changing, and canceling orders can be relatively complex, the user isshielded from this wherever possible by the system 10.

[0278] Each order entered into the system 10 is placed into a queuebased on price and time received. A change to the order may or may notaffect the order's place in the queue. Any change of price will move theorder up or down in the queue depending on the price level. Any decreasein the volume of the order will not affect the order's place in thequeue. Any increase in volume will result in the previous amount holdingits place and a new order placed for the balance.

[0279] Effective electronic trading should be intuitive, fast andreliable. In order to facilitate this, the present invention is designedto maximize a user's efficiency. The system 10 enables the user to placepassive orders from either the market entry interface 250 or marketdetails interface 302 using the input device 86. For instance, the usermay double click on the instrument name or may select the ORD button ofthe function bar 290, 308 in order to launch the passive order interface294.

[0280] Once an order has been submitted, it will immediately be updatedto the market entry interfaces 250 and market details interfaces 302 ofother users, providing the user has a current subscription (i.e., fieldsetting) to the instrument.

[0281] For monitoring the status of a user's outstanding (or open)passive orders, and for making quick adjustments to those orders, thepresent invention has a facility known as an outstanding order blotter320, as illustrated in FIG. 16. The outstanding order blotter 320summarizes all outstanding passive orders and provides the user with theability to confirm the terms of the trade, the symbol, and the type oforder. In addition, the outstanding order blotter 320 enables the userto quickly change the price, quantity, or good until status viadrop-down menus that appear when an order is selected. From theoutstanding order blotter 320, the user may also place new orders and/orcancel a particular order in the market. Thus, the outstanding orderblotter 320 gives the user the ability to manage his/her current passiveorders in the market from a single interface. As with the market entryinterface 250 and market detail interface 302, the user is provided withcancel all, cancel last, and refer-all functions via the outstandingorder blotter 320. This is a significant advancement over many prior artsystems in that not only does the system 10 offer a facility to trackall current passive orders, but the system 10 also enables the user tomodify, add or delete passive orders from the outstanding order blotter320 without returning to the market entry interface 250 or market detailinterface 302.

[0282] For executed or canceled orders, the user is provided a clientmonitor 330, as illustrated in FIG. 17. From the client monitor 330, theuser has access to completed or canceled trades. Thus, the clientmonitor 330 enables the user to quickly see what orders have beenexecuted or canceled, and to look back over time to see pervious daystrades. Preferably, historical transactions will be available for onemonth via the client monitor 330.

[0283] The outstanding order blotter 320 and client monitor 330 enable auser to manage his/her diverse trading activities. From either blotter,the user can monitor the status of orders and executed or canceledtrades. Both of the outstanding order blotter 320 and client monitor 330can be accessed from the command center interface 130. Further, theblotter 320 and monitor 330 are updated automatically if the usersubmits an order via one of the other interfaces.

[0284] The system 10 permits active orders (i.e., those where a traderhits or lifts a passive order) to be placed from either the market entryinterface 250 or market detail interface 302 via the HIT and LIFTbuttons on the function bars 290, 308. The system 10 differs from manyprior art systems in that two passive orders will not be executedagainst each other automatically. An active order from an active user isrequired for execution. Furthermore, there will be one active and onepassive user for each trade. This means choice (where bid equals order)or even backwardation (where bid is higher than order) markets arepossible. Accordingly, for a transaction to be completed in the system10, an action must be performed against a passive order.

[0285] Once an active order has been placed in the system 10, theexecution process is completed. An execution notification message 340,as illustrated in FIG. 18, is sent to both counterparties, describingthe transaction and disclosing the names of the counterparties. Note,this is the first point in the transaction that the counterparties areidentified to one another. The system 10 ensures that both users receivethe message before the trade is finally completed. This does not requireany form of action from either user, the market interface module 74(FIG. 3) of each trader responds for the respective user. Thisvalidation ensures that, in the unlikely event that a connection is lostduring this process, a user does not have a position of which he or sheis unaware.

[0286] The system 10 is designed to ensure that a user cannot execute apassive order which has been canceled or is no longer available. This isdone by checking to verify that the connection between all tradingcounterparties is live at all times. In the event that the connection islost or broken, all orders from a user which loses connection to thesystem 10 are automatically suspended. Following the execution, theclient monitor 330 is updated with the transaction.

[0287] The execution notification message 340 (FIG. 18) provides theusers the opportunity to increase the quantity of a trade once aninitial trade has been executed. One of the users can insert a quantityin the will-do-more field 342 which represents an additional quantity tothe original amount. This feature is designed to enable a user who has alarge quantity to trade to place a passive order for just a smallerportion initially. Users often want the ability to increase the quantityof an order when they have a large quantity to transact. This is becauselarge orders in the market often tend to adversely move the price of themarket as market participants back off such large size. The ability forthe passive trader to conduct an anonymous dialogue via the system 10for increasing the size of a transaction after an initial transactionfor a smaller size has been executed is an additional difference betweenthe system 10 and many prior art systems. In operation, once an amounthas been entered into the will-do-more field 342 and the Submit button344 selected, the counterparty is provided with the request for more.The counterparty is given a discrete period of time to respond to therequest to do more, after which the request lapses. If the counterpartywants to trade more, then the counterparty can accept the amountrequested, reject the amount by selecting the Reject button 346, or thecounterparty can request a different amount that is then present back tothe user who then has a discrete period of time to respond. Thecounterparties can exchange offers to increase the quantity as manytimes as they desire until an addition amount is agreed upon or adecision is made not to do more.

[0288] This function should preferably be made available only if theactive order clears the full market size at the current best price. Inthat case, either party may ask to do more. The will-do-more featureenables the counterparties to increase the size (amount of the trade),but not the price. The price is preferably not affected. This processcan go back and forth for some time and can continue as long as thewill-do-quantity is fully accepted (i.e. can occur more than once). Oncecompleted by both parties, the system will combine all will-do-morequantities and generate only one transaction ticket for the totalincreased amount at the initial price.

[0289] Following the execution of a trade, the system 10 enables theparties to negotiate the non-commercial terms of the transaction. Thisprocess is referred to as term negotiation, and is effectuated throughthe negotiation window 350, as illustrated in FIG. 19. The termnegotiation process is a process where by both parties to a trade havethe ability to negotiate non-commercial terms of a transaction. Inaddition to the commercial terms, such as price, quantity, etc.,derivative transactions also have non-commercial terms which do notaffect the price of the trade. While there are defaults, the parties maywant to negotiate these terms. Once a trade has been executed, thesystem 10 will present the parties with the option to negotiate viainterface 350. The system does not force a party to complete thisprocess immediately, however, as the party may have other more importanttasks to complete elsewhere. The negotiation should, however, becompleted within a reasonable time. The active party (i.e., the traderthat hit or lifted the order) will be presented with the terms 352 to benegotiated, current values 354 which are editable (such as by a textfield), and default values 356 which are predefined in the system. Thetrader may accept the system defaults by selecting button 358, or enterhis/her own desired values and select the submit button 360. Thesevalues are sent to the passive trader (i.e., the trader that placed theorder in the system originally) who may also accept or enter his/herdesired values. If an agreement cannot be reached, then the defaultswill be used. The status of these negotiations will be displayed in theclient monitor 330 of FIG. 17.

[0290] Once a trade has been executed and the non-commercial terms havebeen negotiated, a trade confirmation is sent automatically to thesettlement contact of both business units preferably via fax. The system10 can also send the confirmation via file transfers, e-mail, or anyother suitable means of communication. Preferably, the tradeconfirmation includes the quantity or volume traded, identification ofthe financial instrument that was traded, price, date and time theexecution is recorded, and a settlement ID that uniquely identifies thetransaction. However, it is recognized that various other parameters andtransactional data can be included as appropriate for the nature, typeand subject matter of the transaction.

[0291] In addition to the interactive trading functionality describedherein, the system 10 also offers traders a trading methodology fordealing with risk management problems unique to interest rate swapdealers. In particular, over the last few years, a new market hasemerged as a result of interest rate swap dealers' need to better managetheir risks associated with changes in interest rates on their growinginterest rate swap portfolios. With these markets becoming morecompetitive, bid-offer spreads are narrowing considerably. This factor,combined with the wide spreads of exchange traded Eurodollar futures,has contributed to the use of exchange traded contracts for hedgingshort-term risks being expensive and sub-optimal. As a result, theswitch was created. A switch is simply the simultaneous purchase andsale of a pair of similar forward rate agreements. This instrument, andthe mutually offsetting need of a pair of derivative portfolio riskmanagers, provide an improved risk management tool for a large portfolioof interest rate swaps. Despite the obvious advantages and demand fromrisk managers, as a result of the complexity and time-consuming natureof completing a transaction, the switch market has grown relativelyslow. This may be because risk managers are very wary of disclosing theexact nature and size of their own portfolios. Therefore, finding thecounterparty that has the opposite need is often difficult.

[0292] Typically, a dealer prepares a fax listing the days that thedealer needs to buy or sell, but not the amount or importance of anygiven date. The dealer sends the listing to other risk managers at otherfirms, or to voice brokers. From this bit of incomplete information,transactions are eventually negotiated. While finding switches may beimportant, it is usually not urgent as compared to other more immediatetasks, such as new executions or the hedging of large outright marketrisks. As a result, the time is never quite right to focus on a positionthat may be heavily weighted on one side and matches another's position,but not perfectly. Voice brokers have tried to solve this by matchingmultiple faxes, but this does not appear to be the solution.

[0293] The present invention goes several steps beyond these efforts,and offers matching with the credit preferences of the traders takeninto account. The system 10 also demonstrates fairness in any matchingprocess. When the portfolios are so large that each risk manager has aposition on each day out over the life of his or her portfolio, theresulting combinations can be huge. The rules, constraints andpriorities are preferably structured in a way to demonstrate fairness ofexecution between users to the market participants.

[0294] In a significant departure from known attempts by others, thepresent invention offers traders a solution to the complexities ofswitch trading by creating an anonymous position discovery system calledthe switch engine. The objective of the switch engine is to put a toolin the hands of risk managers that allows them to perform anonymousswitch transactions fast and efficiently without losing control of theprocess. The switch engine achieves this by having the trader manuallyinput his/her position (i.e., interest rate risk portfolio) into theswitch module 80 (FIG. 3) via a portfolio interface 380 using variablerate index and currency for up to 180 days or more into the future, asillustrated by FIG. 20. Once a portfolio is inputted, the user mustconfirm its accuracy by selecting the Apply button 381 before thepositions can be used in the switch mechanism 35 of the centralprocessing center 12 (FIG. 2).

[0295] In addition, the system 10 can be configured to receive theposition data via electronic transfer or some other suitable form ofdata transfer. This may include a transfer directly from the user's ownrisk management systems. Although some trader workstation 20 may needsome customization to receive portfolios in this matter, the system 10should support this capability. The nature of switch positions,particularly in the near term (defined as out to the maturity of eachindex), is relatively stable, and therefore, the on-line entry ofportfolios by the user should be adequate for most traders. The inputtedportfolio data is then sent from the trader 20 workstation to the switchmechanism 35 of the central processing center 12.

[0296] With reference to the portfolio interface 380 of FIG. 20, aninputted column 382 represents the portfolio entered by the user, thetraded column 384 is the cumulative amount traded by the user since theportfolio was entered in the inputted column 382. The net column 386 isthe real-time position of the user given the portfolio inputted and thetraded quantities in column 384. The user may restart at any time byrolling the net positions in net column 386 into the input column 382 byselecting the Roll button 388, or by clearing all the positions byselecting the Clear button 389.

[0297] Once the position is inputted in the system 10, a switchinterface 400, as illustrated in FIG. 21, is generated by the switchmodule 80 using his/her own position data from other traders entered onthe respective trader workstations 20 and uploaded to the switchmechanism 35. The switch interface 400 enables the user to searchthrough the market, and view possible trading combinations of his/herportfolio and combinations of his/her portfolio against positions fromother counterparties which have been input into the system. This isreferred to as position discovery. The switch interface 400 can bereached by selecting the switch engine button in the tool bar 132 of thecommand center interface 130 (FIG. 5). For a given floating rate index(for example, a one month LIBOR) 402, the switch engine interface 400lists the net positions 404 for each day 406 out 180 days. In addition,the possible switches 408, available switches 410, formulated forwardrate 412, and a fair price 414 are also listed for each day 406. Byselecting a day 406, the switch interface 400 displays all possibleswitches against that day. Thus, the user can pick the days for whichhe/she is carrying the most risk. An advantageous feature of the switchinterface is that the user is provided with only combinations wherehe/she has a position and someone else has the opposite position, andboth parties satisfy each other's credit preferences as described above.

[0298] The net position 404 is the position entered or modified by theuser. Possible switches 408 are those switches for any given day withrespect to the trader's own position. Note, a switch typically makessense only if the trader's position is long one day and short on anotherday.

[0299] The available switches 410 are positions in other counterpartyportfolios that exactly offset the position of the user. Note that theswitch interface is configured to displays available switches up to thesize of the user's own position, and preferably does not disclose thename(s) of any counterparties until after a trade has been completed.This ensures the anonymity of the user, and does not disclose anymaterial position data to other traders.

[0300] The forward rate 412 is the current market forward ratecalculated by the system from other available market rates for the givendate for the maturity of the underlying index maturity. The fair price414 represents the relative price between the two underlying FRAs, whichis the basis upon which forward rate agreements are traded. The fairprice 414 is calculated from live market data taken from other financialinstruments. While not designed to execute trades at the displayed fairprice 414, the fair prices are an aid to users in gauging the fair valueof the market.

[0301] Once a user has found a switch that matches the needs of theuser, that is shown as an available switch 410, then the user may send arequest for switch message by selecting the request for switch (RFS)button 416. In response thereto, an RFS message is sent anonymously toonly the other counterparties of the selected offsetting positions.Anyone of the receiving counterparties may then add the symbolautomatically into a market entry profile by selecting (i.e., clickingon) the message and completing the transaction utilizing the marketentry interface 250, as described herein. Upon completion of a switch bythe switch mechanism 35, the portfolio's of the counterparties areautomatically updated to reflect the switch. In accordance with afeature of the switch engine, switch transactions can be accomplished inreal-time.

[0302] As an example of a switch, a trader viewing the switch interface400 may select (i.e., highlight) the “Thurs., August 21” position, andthen select the RFS button 416. The passive order interface 294 (FIG.14A) then prompts the trader with a quantity and price which the tradermay modify. The trader may then submit the request for the switch. Allanonymous counterparties that have an offsetting position then receive amessage in command center interface 130 (FIG. 5) notifying thecounterparty of the anonymous request for a switch. Any one of thecounterparties may then select the request message which causes therequest to be displayed in the market entry interface 250 (FIG. 12).From the market entry interface 250, the counterparty can hit therequest for switch or submit their own passive order.

[0303] The trader can update or modify his/her portfolio by selectingthe Update button 418, which launches portfolio interface 380, asdescribed above. The trader can then select an inputted amount 382 or atraded amount 384 to enter or edit the displayed values as desired.

[0304] It should be noted that the present invention has application infinancial markets other than derivatives. For instance, in theinter-dealer market, a switch or swap may be a desirable means by whicha risk or inventory short fall is off-set. In particular, a security maybe borrowed or an open derivative position hedged with another position.For instance, in the U.S. Treasury bond market, it is conventional fortraders to buy and sell securities, and to hedge with the newest orbenchmark issues. The U.S. Treasury may issue new two year securitieseach month. For the first month, the new issue is the benchmark (oron-the-run) issue, and the other issues with a final maturity betweenone and two years are referred to as old issues. If a trader is asked tobuy an old issue, then the trader will sell the on-the-run as a hedgesince the on-the-run has the liquidity. Over time, the trader will mostlikely need to sell the old issue and buy back his/her hedge. A switchwith another dealer that has an opposite position provides cost and riskeffective method of effectuating such a trade.

[0305] However, the unwillingness of traders to disclose their positionhas made bond switches difficult. Thus, the switch engine of the presentinvention is a solution. The principals of the switch engine can besuccessfully applied to bond switches, as well as other financialinstrument switches. The switch engine interface 400 may need to beslightly modified wherein the instrument designation 402 is changed toreflect the new market, for instance, to Two Year U.S. Treasuries or 30FHLMC TBA. Further, the setting column 406 may be changed to reflect theindividual securities which may be switched, and the remaining columnsshould not need to be changed. However, a new column representing theduration of each security displayed should be added so that thesecurities can be duration weighed to ensure fairness.

[0306] In addition to the switch engine, the system 10 provides tradingmethodologies referred to as the auction and switch auction. Althoughauctions are held in a variety of markets, some of which are electronic,the auction and switch auction have no known counterpart in thederivatives markets. The auction and switch auction tradingmethodologies were developed in order to provide an auto matchingprocess for switches. However, the system 10 can use these auctionmethodologies for auto matching for a wide variety of other financialproducts, not just switches.

[0307] Unlike traditional auctions, where once a trade is completed thecounterparties are free from future financial commitments, withderivatives trading, the counterparties may end up with multi-yearfinancial commitments to one another once a trade is executed. In orderto deal with this relatively unique problem, the auction and switchauction take the credit preferences of the users into account. Theauction methodologies herein are referred to as a two way Dutch auctionwith credit. In conducting such an auction, users submit orders into theauction module 81 of the trader workstation 20 (FIG. 3) whichcommunicates the information to the auction mechanism 34 of the centralprocessing center 12 (FIG. 2). The orders are submitted via an auctioninterface 430, as illustrated in FIG. 22A, by price, quantity, andaction.

[0308] With reference to FIG. 22A, the auction interface 430 includes aqueued orders window 432 into which the user enters an order, and asubmitted orders window 434 which shows the orders submitted to theauction mechanism 34 via the auction module 81. Orders can be added viathe Add button 436. Orders are moved from the queued orders window 432to the submitted orders window 434 by highlighting the order and thenselecting the Submit button 438. All entered orders in the queued orderswindow 342 can be submitted at once by highlighting all the orders andthen selecting the Submit All button 442. Prior to submitting an order,the orders in the queued orders window 432 can be edited via the Editbutton 440 or canceled via the Cancel button 444.

[0309] In accordance with the auction, the orders are filled at theirentered price or better, and between counterparties that satisfy thecredit preferences of one another. The auction mechanism 34 thenconducts the auction, preferably utilizing the following constraints andpriorities to ensure fairness.

[0310] The auction price is calculated by finding the price at which themost volume is traded. This condition is sufficient to generate a fairprice, and all transactions should be completed at this price. It isnoted that this price is generated without taking credit into account.The matching of orders is completed to ensure that credit preferences(including complex rules) are safe guarded and to ensure that theminimum number of tickets are generated. The better submitted priceswill have priority, and all orders at the auction-price are filled inproportion to each other. Under these constraints, the auction mechanism34 executes the auction, matching users and generating a settlementlist. The settlement list comprises the trades resulting from theauction.

[0311] The confirmation process is substantially the same as that forinteractive trades. The system 10 notifies the users of their fills.Finally, results will be made available to the user via a message to thecommand center interface 130 of each user.

[0312] In addition to the general auction facility described herein, thepresent invention also offers a dedicated limited auto-matching processfor switches referred to as the switch auction. The switch auction doesnot have to be a full auction, in that the price may be set by thesystem 10. The price will, however, be available before the commencementof the matching. This will allow all users to understand the levels thatwill be used before entering into the switch auction. This also allowsthe users to maintain control of their positions.

[0313] As with the general auction, the positions of each trader areloaded into the system 10 utilizing a switch auction interface 460, asillustrated in FIG. 22B. The switch auction interface 460 has two parts,an auction list 462 and an auction status 464. In the auction list 462,various auctions and their respective statuses are listed by FLOPT andcurrency. In the auction status 464, the auction selected in the auctionlist 462 is displayed and identified (including the open and closeday/time). The positions 466 for respective dates 468 are entered by auser, and do not need to add to zero, but should include positions ofboth signs (i.e., long and short). The rate 470 is the price at whichthe auction is conducted. The rate 470 is displayed a predeterminedamount of time before the auction is conducted so that the participantshave the opportunity to step out of the switch auction if they sodesire. The rate is preferably based on available market factors, andmay be calculated by a calcserver (as described below). The resultscolumn 472 is the total trade amounts resulting from the auction. Theamount displayed in the results column 472 for a given date may be thecumulative amount from multiple transactions with multiple parties.Additional control buttons 474 enable the user to submit an order,cancel an order, cancel all orders, or change an order. The switchauction will auto-match the position, taking credit preferences of theusers into account so that (1) a maximum volume is executed and (2) aminimum number of tickets is generated.

[0314] The switch auction utilizes the above two rules to ensurefairness. No user will be given priority over any other user except asrequired to satisfy the respective credit preferences. Preferably, onlytwo-way switches will be offered. Switches are a risk management tool,and switches generated between three counterparties introducessubstantially more credit risk than a straight two-way switch.

[0315] At this point, the calcserver which calculates the auction rateand price information, and other relevant data for operation of thesystem 10 is described. The calcserver provides the switch mechanism 35with the forward rate for any given index for each day, the system pricequoted in the market entry interface 250, and OTC derivative pricesderived from the yield curve. The calcserver comprises a preprocessor, azero curve server, a FRA server and a Swap server. The preprocessorgathers real-time data from outside data vendors (such as Reuter orTelerate) and from internal system sources (such as data normallyentered into system 10), and prepares the data for processing by theother components of the calcserver. The zero curve server reads in themarket rates (including price and yield for a variety of classinstruments such as money market rates, swap rates, future prices, swapspread, bond yields and FRA's) as provided by the preprocessor, andgenerates therefrom the zeros and discount factors for each currency andlevel of credit. In particular, a zero coupon yield curve (i.e., zerocurve) comprises a set of points representing the calculated interestrate or discount fact from observable market rates across the termstructure (e.g., 0 to 30 years) such that any cash flow can bediscounted to today in one step without the consideration withdecompounding. Thus, there is a different zero curve for eachindex/currency pair. The FRA and Swap servers are instrument specificservers that calculate forwards, RQ (as defined above), durations andfair prices.

[0316] By way of example, the zero curve calculation starts from theinstruments with the shortest term structure in the money market rates(MMs). The analytics for finding points on the zero curve from MMs areas follow. The processed price of the MMs, end date of the MMs and thebasis of the MMs (number of days in a year that the MMs is based on) areneeded. All of these are stored in a database 64 (FIG. 2). The processedprice is the only input that typically changes. The calculationrepresented by the equation below will generate a new zero rate with thedate of the end date of the MMs. The result will be a new zero pointwhich will be added to the rest of the generated zero points. Thefollowing equation for Z(t) is the zero rate at the end date of the MMs:${z(t)} = {\left( {1 + {R_{mms}*\frac{t}{mmsBasis}}} \right)^{365/t} - 1}$

[0317] where Rmms is the processed price of MMs, and t is the time indays between the end date of the MMs and the current date.

[0318] After the MMs, the next instruments used according to termstructure are either the futures or FRA's. Since the futures and FRA'shave similar term structures, a choice will be made on which ones touse. Initially the futures will be used because they have highliquidity. However, it is believed that when FRA's traded on the system10 reach a high level of liquidity, they should be used instead.

[0319] When calculating zero points from the futures, the processedprice, the future basis (number of days in a year that the future isbased on), the start date of the future, the end date of the future andthe zero point of the start date are needed. This data about the futurewill come from the preprocessor which is used to represent the future.The zero point at the start date is found from previous zero pointsthrough interpolation. The following equation for z(e) is the zero rateat the end date of the future.${z(e)} = {\left\lbrack {\left( {1 + {{futRate}*\frac{e - s}{futBasis}}} \right)\left( {1 + {z(s)}} \right)^{s/365}} \right\rbrack^{365/e} - 1}$

[0320] where futBasis is the number of days in a year that the future isbased off, futRate is the processed price of the future, e is the enddate minus current date, and s is the start date minus the current date.

[0321] The calculation of the FRA zero points is the same as for thefutures except that the processed price for the FRA and the FRAbasis areused instead of the processed price for the future and the futurebasis.The information about the FRA will come from the preprocessor. Thefollowing equation for z(e)_(fra) is the zero rate at the end date ofthe FRA:${z(e)}_{fra} = {\left\lbrack {\left( {1 + {{fraRate}*\frac{e - s}{futBasis}}} \right)\left( {1 + {z(s)}} \right)^{s/365}} \right\rbrack^{365/e} - 1}$

[0322] The rest of the zero curve will be derived from swap information.For the first swap, the zero curve and the discount factor at eachcoupon date are used to calculate the zero rate and the end date in theswap using the equation below for Z(t_(n)). When calculating other swapzero points, gaps may exist in the zero curve. Synthetic swap rates arecalculated where gaps exist to improve accuracy. The calculation of anormal swap rate and a synthetic swap rate are the same. The followingequation for Z(t_(i)) is the zero rate at the particular coupon date:${Z\left( t_{n} \right)} = {\left\lbrack \frac{1 + {{swapRate}*{Y\left( {t_{n - 1},t_{n}} \right.}}}{1 - {{swapRate}*{\sum\limits_{i = 1}^{n - 1}{\frac{Y\left( {t_{i - 1},t_{i}} \right)}{\left( {1 + {Z\left( t_{i} \right)}} \right)}{t_{i}/365}}}}} \right\rbrack^{365/t_{n}} - 1}$

[0323] where swapRate is tradePriceAdjust, t_(i) represents a coupondate, and Y(t_(n−1),t_(n)) is the period in years between the two coupondates. Once the trades have been executed and the term negotiationprocess completed, the system will initiate an automatic confirmationprocess which, in an embodiment of the present invention, will followexisting market practices. Accordingly, the system 10 will automaticallysend a fax confirmation message to each counterparty detailing thetransaction. The faxes should be sent immediately after a transaction iscompleted. The confirmations should follow a unique format, allowing theautomatic transfer of these confirmations electronically.

[0324] This confirmation has been specially developed to allow for astandard format covering all classes of financial contracts. Thestandard confirmation follows the following format:

[0325] Section 1: Summary of the transaction.

[0326] Section 2: Counterparty details and commission.

[0327] Section 3: Transaction details.

[0328] Section 4: Term negotiation

[0329] This provides the users with adequate information to identifyand/or record the transaction. The conformation, however, may be sent tothe traders any number of ways such as via e-mail, voice-mail, UnitedStates Postal Service, or commercial carrier (e.g., FedEx, UPS, etc.).Further, it is noted that the information provided can take many otherformats within the scope of the present invention.

[0330] While the various interfaces to system 10 have been describedherein as individual windows, it is noted that multiple windows can beintegrated to form a main screen 480 with multiple frames, asillustrated in FIG. 23. For instance, a tools area 432 provides thetrader with a set of customized tools including graphs, market quotes,bond prices to yield converters, pricing tools, and MarketSheet™applets. A service area 484 provides various interfaces as describedabove on a temporary basis. A message center 486 displays the mostrecent RFP, RFS, Chat and administrative messages, and is preferablyconfigured as a drop-down window to display multiple current messages. Astatus bar 488 displays user status information. A workspace area 490provides for the entering of data into dialog boxes in a non-intrusivemanner, plus the execution of the data function. A warehouse area 492stores the most commonly used interfaces in a tabbed format, allowingthe trader to retain their preferred set-up between sessions.Accordingly, the main screen 480 provides enhanced functionality byintegrating multiple interfaces in a single window.

[0331] IV. Operation

[0332] As described above, the system 10 comprises the centralprocessing center 12 that may includes multiple servers connected via anInternet-protocol network to the individual counterparties traderworkstation 20 which may be desktop computer workstations. Because ofthe open system architecture of the system 10, the present invention mayrun within the context of the internet browser 72 on the user's existingdesktop computer 20. The desktop computer 20 preferably includes anoperating system platform for which a Java-enabled Internet browser isavailable.

[0333] In order to provide the counterparties with anonymous creditpreference based trading capability for a wide range of financialcontracts where each side enters into a long-term contract with theothers, the present invention is designed to be flexible enough toreflect several different measures of credit risk, as generallydescribed below with reference to FIG. 24.

[0334] With reference to flowchart 502 of FIG. 24, each business unit(counterparty) provides the group server 32 (FIG. 2) with detailedcredit preferences for each potential counterparty business unit's legalentity. The group server 32 then distributes the credit preferenceinformation in an anonymous format to the trade workstation 20 whichuses the credit preferences of each active business unit (counterparty)in the system 10 to prescreen the user's market orders (bids and offers)against the other counterparties' market orders. Thus, the creditpreference module 76 (FIG. 3) of each trader receives the creditpreference information defined by a first user with respect to a seconduser, as indicated by block 504. The credit preference module 76 thenreceives the credit preference information from the second user withrespect to the first user, as indicated in block 506. The creditpreference module 76 then determines which orders, on which financialinstruments, and with which counterparties, the user can deal. Thisinformation is coding on the posted prices utilizing color or anothernotational method such as symbols, as indicated in block 508.

[0335] In accordance with an aspect of the present invention, theprescreening is a complex check to determine whether two particularcounterparties will accept each other for a particular class offinancial instrument, for a particular amount and for a particularmaturity. This is a risk equivalent measurement, and is more than asimple yes/no preauthorization matrix. More specifically, because eachfinancial instrument has different credit qualities, it is possible fora particular counterparty to be willing to accept another particularcounterparty for one type of financial instrument but not another.Furthermore, it is also possible that a particular counterparty mayaccept the other for a particular financial instrument, but only for acertain length of time (i.e., maturity). The system 10 may also allowthe user to accept counterparties for different amounts at differentmaturities.

[0336] It is further noted that the system 10 divides counterpartiesinto legal entities. These legal entities may be further divided intoindividual business units. So, for example, Bank A may be a legal entity(counterparty) and Bank A might have a different business unit in threedifferent cities (e.g., Tokyo, London, and New York). In this example,the counterparty credit information is available at the legal entitylevel. So, for instance, if Bank A wishes to allow each of its businessunits to set their own credit preferences for other counterparties, thenthese credit preferences will be listed against the legal entity levelof all the other business units. In other words, business unit A at BankA can not say it will trade with desk A of Bank B but not desk B of BankB. The system 10 allows business units within a particular legal entityto inherit the credit preferences from other business units in the samelegal entity family, if so desired.

[0337] Once each business unit has inputted their individual creditpreferences, this credit preference information is maintained locally atthe inputting trader workstation 20, and transmitted to the group server32 of the central processing center 12. The central processing centerthen transmits a vector of encoded credit preference data to each userlogged on, wherein the data represents that preferences of the user tothe other legal entities and the preferences of other business units tothat user's legal entity for the affected instrument classes. Theencoded vector of credit preference data is accessible to any of thetrader workstations 20 in the system 10; however, the sensitive creditinformation of other counterparties is not available.

[0338] Once the user has inputted his/her business unit's creditpreferences, the user is then able to select or filter messages on whichfinancial instruments and in which currencies the user wishes to receiveupdates, messages and prompts. The filters can be selected via the userpreference interface 148 to customize the order information presented bythe command center interface 130. This screening capability is providedto the user in order to prevent him from being overwhelmed by, and tosort through, the possibly thousands of different financial instrumentsin up to or more than 14 different currencies that the system 10 has theability to handle. Once these filters have been inputted into the system10, the user is able to view trading information on the currencies andfinancial instruments that have been selected for the user. This means,for example, that if the user has selected US dollars only, then theuser will preferably not see information on the Japanese Yen financialinstruments which are in the system 10 for trading.

[0339] Once the trading preferences of the user have been entered intothe system 10, the user can proceed with trading. The user thenactivates the fully customizable, re-sizable market entry interface 250.The market entry interface 250 enables the user to input many differentfinancial instruments which the user is interested in trading on onescreen, and have any number of profiles wherein each profile is acollection of markets or a collection of financial contracts in thesystem 10.

[0340] A preferred embodiment accomplishes the inputting and referencingof the various financial instruments through the use of a unique set ofsymbols referred to as symbology. The symbology of the present inventionis based on a concept of subject based addressing whereby the usercreates a symbol to uniquely define any one of many complex financialinstruments. The symbol denotes the financial instrument's parametersand attributes. The standardized symbology of the present invention isdesigned such that the users of the system 10 will recognize the meaningof the symbol when the users view the symbols. To further help the usersunderstand which financial instrument they are trading, a symbol may beidentified by the full subject name, an alias (in the case of the mostcommonly traded instruments), or a unique identifier (e.g., such as anumeric code). In order to help the users use the symbology to properlyexpress the financial instruments they want to trade, the system 10allows the users to construct symbols utilizing the symbol constructioninterface 270 (FIG. 13).

[0341] The symbology of the present invention, as described below and asillustrated flowchart 510 of FIG. 25, enables a user to input dataincluding a proposed trade of a financial instrument, wherein thefinancial instrument is advantageously defined by symbology comprising asource field, a class field, a symbol field and a currency field, asindicated by block 512. This abbreviated format for identifying afinancial instrument can then be easily transmitted to other userswithin the system 10, as indicated by block 514. At the receiving userstrader workstation 20, the proposed trade can be viewed by the tradersutilizing the symbology, as indicated by block 516. By defining thefinancial instrument using the symbology of the present invention, theusers can exchange a small amount of data that is translatable into adetail description of a financial instrument that is relatively complex.This reduces communication and processing overhead of the system 10 andsimplifies the user's efforts.

[0342] Once the orders have been inputted via the symbology, the marketentry interface 250 displays the best bid and best offer for eachinstrument, as well as the sum quantity available to trade at the bestprice and other relevant information. The order information (i.e., thebids and offers for each instrument) is coded with the relevant creditpreferences, unless several prices are currently posted at the sameprice but have different credit status, in which case the market detailinterface 302 should be used. This is significantly different from someprior art systems which only show the best dealable price. The system 10presents the best price, irrespective of credit preferences or creditlimits. From market entry interface 250, it is possible for the user toexecute a trade directly if the credit preferences of both partiespermit. The user may also place a passive order from the market entryinterface 250.

[0343] The user also has the option of activating a market detailinterface 302 which enables a user to see the complete picture (i.e.,depth) of all the orders (e.g., bids and offers) available on aparticular financial instrument, coded with credit preferenceinformation. The market entry interface 250 and the market detailinterface 302 not only display the best bid and offer, but eachindividual order in the system 10 individually. Through the market entryinterface 250 and the market detail interface 302, the user is providedthe ability to select not just the best bid or offer, but any bid andoffer in the system 10. This is important because for credit reasons,the viewing counterparty may not wish, or may not be allowed to, trade aparticular bid or offer. This means that the best bid or offer in thesystem 10 is not necessarily the best bid or offer available to thatcounterparty.

[0344] The credit preference information entered in the system 10 byeach user, as described above, is used by both the central processingcenter 12 and the transmitting business unit servers 18 to prescreen thebids and offers, and to market orders in the system 10 before they areviewed at the trader workstations 20 of the respective client sites 14.The sensitive credit preference that indicates which counterparties areacceptable, and under what terms, is preferably maintained at thetransmitting trader workstation 20 and the central processing center 12.The other viewing users do not receive or have access to the creditinformation of the other users. At the receiving business unit's server18, a check is performed to determine whether the receiving client site14 will accept the particular bid or offer from the transmitting legalentity. The summary and relevant data is transferred in an encryptedform to trader workstations 20. The credit check may be re-performed atthe time of a transaction by the central site 14 and/or the centralprocessing center 12.

[0345] The credit preference screening of the present invention enablesthe display of all passive orders in the system 10 and their relevantcredit status with regard to the viewer on both the market entryinterface 250 and the market detail interface 302 as follows: 1)green—this means that the viewer accepts the posting counterparty, andthe posting counterparty accepts the viewing counterparty; 2)yellow—this means that the viewing counterparty will accept the postingcounterparty but that the posting counterparty will not accept theviewer; 3) red—that the viewer will not accept the poster; 4) blue—thatthe bid or offer being looked at is the viewer's own; 5) white—used onthe market entry interface 250 to denote when two or more orders areplaced at the same price but with different credit preferences. The useof color coding enables the system 10 to preserve the anonymity of theusers while still enabling the viewing business units to receive creditinformation about the bids and offers they are viewing. In the event theuser is color blind, the system 10 also includes the option to displaysmall symbols next to each price to indicate the relevant credit statusto the viewer.

[0346] If the viewer wants to trade a green bid or offer, then thesystem will permit this to be executed right away. Further, if theactive counterparty to the transaction, that is, the viewer who hit thebid or lifted the offer, chooses to execute the full size of the amounton offer or bid and there are no more orders at the same price, theviewer will be prompted with the ability to ask the other counterpartyto do more. This will-do-more feature is preferably restricted to apredetermined time-limit in which the receiver of the request mustrespond. The receiver of the request may agree to accept the increasedquantity (or part of the increased quantity) at the previously agreed toprice or the request will lapse. The will-do-more feature may berepeated as many times as the users desire. The will-do-more featuredoes not necessarily check credit preferences once this process hasbegun because both users know the identities of each other at thispoint. This forces the users to take responsibility for further creditapproval beyond the point of the initial trade amount.

[0347] If the order being viewed by the user is yellow, then the viewerwill accept the poster but the poster will not accept the viewer. Inthis case, the system 10 enables the viewer to send a credit overridemessage to the poster of the bid or offer whereby the sender of thecredit override reveals his/her identity to the poster and asks theposter to reconsider whether or not the poster will do the requestedtrade with the viewer. In this case, the user which sent the creditoverride will be identified to the poster, but at no time will thesender of the credit override find out who they revealed themselves to.If the poster chooses to accept the credit override, then the poster mayalso choose to impose additional credit requirements on the viewer inorder to accept the transaction. These additional credit requirementswould be in the form of a standard mutual put clause in the confirmationof the trade. The viewer will have the opportunity to either accept ordecline the additional credit requirements. The credit override functiondoes not in anyway change the credit preferences which each userpreviously input into the system 10. The credit override is preferablyon a per-transaction basis.

[0348] If the bid or offer viewed by the viewing trader is in red, thenthe viewer will not accept the poster. Despite the fact that the viewerknows he/she will not accept the poster, the viewer does not know whichamong the counterparties he/she will not accept is the poster. Theviewer is thus not able to identify the poster, preserving the anonymityof the system 10. If the poster does not activate the credit override,then no trade will be able to take place.

[0349] If the bid or offer displayed is in blue, then the order is theposter's own order. The system 10 does not prevent different userswithin the same client site 14 from trading with each other.

[0350] From both the market entry interface 250 and the market detailinterface 302, it is also possible for the user to send arequest-for-price message to the other counterparties that areinterested in the requested financial instrument. The request-for-priceenables a user to anonymously broadcast to other interested marketparticipants.

[0351] With reference to FIG. 26, a flowchart 520 generally describesthe steps of a trade. Initially, the first user and the second user areprovided with essentially real-time order information regarding morethan one financial instrument typically via the market entry interface250, as indicated by block 522. The order information preferablyincludes a request to buy or sell a financial instrument such as an OTCderivative. At block 524, one of the first or second users initiates thetrading process on an order selected from the order information providedby the other of the first or second users. The credit preferenceinformation of each user is then used to verify the trade eligibility ofthe first and second users with regard to one another based on theselected order, as indicated by block 526. One or both of the first andsecond users are then able to request an increase in the quantity of theorder, as indicated by block 528. If an increase is requested, therequest is process at block 530. Alternatively, if there is no requestto increase the quantity at block 528, it is then determined that block532 if there is a request to negotiate terms of the order, and moreparticularly, the noncommercial terms of the financial instrumentunderlying the order. If there is a request to negotiate terms by one ofthe users, then the request is processed at block 534. If there is not arequest to negotiate terms, then an acknowledgment is sent to both userssignifying the execution of the trade, as indicated by block 536.

[0352] The trade process as described above with reference to FIG. 26can also be described from the perspective of the first and secondusers. For instance, with reference to FIG. 27A, a flowchart 540generally depicts the steps of a trade from the perspective of a passiveuser. Initially, at block 542, the credit preferences of the user areinputted and distributed to the other users for effectuating the creditpreference screening. At block 544, the user sends an order to system 10for distribution to the other users requesting a trade on a financialinstrument. The user that placed the order must then wait for anothertrader to hit or lift the passive order, thereby executing the trade.Both parties to the trade will receive an execution notification whichwill allow one or both users to request an increase in quantity, asdetermined by block 548. If this request is received from the partyhitting or lifting the passive order, the first user accepts, denies, oramends the requested increase, as indicated by block 550. If there is norequest to increase a quantity, then it is determined at block 552whether there is a request to negotiate terms of the financialinstrument. This feature allows the users to change the default valuesfor the non-commercial terms of the financial contract, as indicated byblock 554. Next, the first user will receive an acknowledgment of theexecution of the trade with the second trader, as indicated by block556.

[0353] With reference to FIG. 27B, a flowchart 560 generally illustratesthe steps of a trade from the perspective of the active user that liftedor hit the passive order. At block 562, the second user receives anorder from the first user requesting a trade on a financial instrument.The order is then checked for trade eligibility based upon the creditpreferences of the first and second users, as indicated by block 564 Theorder is coded with appropriate credit information based upon the creditcheck, as indicated by block 566. The coded order is then presented tothe second user based upon a preference or filter set by the second userto view orders of the present instrument, as indicated by block 568. Thesecond user then initiates a trade by lifting or hitting the order, asindicated by block 570. In block 572, it is determined if there is arequest to increase quantity. If there is not a request to increasequantity, then the request is processed at block 574. If there is not arequest to increase the quantity, then it is determined at block 576whether there is a request to negotiate terms of the financialinstrument. This feature allows the users to change the default valuesfor the non-commercial terms of the financial contract, as indicated byblock 577. Next, an acknowledgment is received by the first and secondusers indicating that the trade has been executed, as indicated by block578.

[0354] Another feature of the present invention is the positiondiscovery as illustrated by a flowchart 580 of FIG. 28. At block 582,risk position portfolios are received from the users of system 10. Atblock 584, relative position information is calculated for each user sothat each user may be presented with possible trading combinations fortheir portfolios, and combinations of their portfolios against positionsfrom the other users. The possible trading combinations are coded withcredit preference information in accordance with the present invention.It is then determined at block 586 if a switch is requested. If a switchis not requested, then the process ends. However, if a switch isrequested at block 586, then a switch is executed at block 588. Theexecution of the switch is performed in substantially the same manner asany other trade, as described above. Upon execution of the switch, theposition information of each party to the switch is automaticallyupdated to reflect the switch, as indicated by block 590.

[0355] A blotter is provided to enable the user to keep track of all theorders he/she has inputted into the market. The blotter is preferably ascreen whereby once it is activated, it displays all the outstandingorders a user has in the system. The blotter enables the user to monitorall his/her outstanding orders in many different instrumentsconveniently in one place. Preferably, there are two types of blotters.The first is the outstanding order blotter 320 which offers severalfunctions to the user for managing his/her orders, such as the abilityto change the price, or size of an order. This is accomplished throughthe use of dials on the windows which enable the user to quickly dial upor down the price without needing to cancel and then re-submit theorder. This edit process shields the user from the complexity of ordermanagement regarding changed orders. This also prevents the user fromaccidentally having duplicate or no orders in the system 10. Theoutstanding order blotter 320 also enables the user to quickly suspend(or refer) all of his/her active orders in the system 10, and thenre-input them one by one or delete them as necessary. Yet further, theoutstanding order blotter enables the trader to cancel one or all of hisorders. The second type of blotter is the historical order blotter 330.From the historical order blotter, it is possible for the user to viewall of his/her previously executed trades and the respective status, aswell as those that have been canceled.

[0356] In order to address the needs of interest rate swap traders andportfolio managers, the system 10 may include a function known as theswitch engine. The switch engine is implemented by a switch interface400 and enables the user to input an entire portfolio of interest ratereset risks into the system 10, and then view out into the future for anunlimited time horizon on a daily basis. In a preferred embodiment, theuser inputs the size (in millions) and the direction (receiving orpaying) of the reset risks portfolio into the system 10 on a wide rangeof the most common interest indices (i.e., 1 month US dollar libor, 3month US dollar libor, 1 month DEM libor, etc.). The portfolio can beinput either directly through the portfolio interface 380 (FIG. 21), orby uploading a file with the required information. Once the informationhas been input into the system 10, the user is then asked to confirm theinput. Once this information has been confirmed, the user then has theability to anonymously look at his/her interest rate reset risk positionrelative to all other counterparties who have inputted such informationto determine based upon credit preferences, which trades are availableto him/her in the system 10 to off-set his/her interest rate resetrisks. Once the user has located these trades, the user can thenanonymously send a request-for-switch to the other counterparties in anattempt to initiate a trade.

[0357] The system 10 further provides the functionality to permit thetrading of various financial instruments via an auction function, asgenerally illustrated in a flowchart 600 of FIG. 29. The system performswhat is referred to herein as a two way Dutch auction with creditpreferences. In this auction methodology, users submit orders into theauction giving both the price and the quantity at which they wish totrade, as indicated by block 602. The auction process then begins bycalculating the price at which the most volume is traded, as indicatedby block 604. This is called the auction-price. The auction-price is afair price at which all transactions will be completed. In thiscalculation, the credit preferences of the various counterparties arenot yet taken into account. At block 606, the system matches up orderssuch that all credit preferences are taken into account such that theminimum number of tickets are generated. The better submitted priceshave priority, and all orders at the auction-price are preferably filledin proportion to each other. In a preferred embodiment of the auctionfeature, the auction process could be conducted a few times a day inorder to maximize liquidity. The system also offers the functionality toenable the user to trade forward rate agreement switches and otherswitch products in an auction environment similar to that describedpreviously.

[0358] The system then automatically generates a confirmation for eachtransaction and sends it electronically via email, fax, or another meansto the counterparties of each executed transaction, as indicated byblock 608. This unique confirmation process has been designed to use astandard and consistent format for all financial instruments.

[0359] At this point, a more detailed description of the operation andfunctionality of the auction mechanism 34 is provided. With reference toFIG. 30, the auction mechanism 34 initially receives an order list fromthose traders wishing to participate in an auction, as indicated byblock 620. The orders within the order list are separated into a BuyListand SellList, as indicated by block 622. At block 624, a price list isgenerated and sorted from highest price to lowest price. It is thendetermined at block 626 whether an auction will take place bydetermining if the price list is empty. If the price list is empty, thenno auction takes place, as indicated by block 628. If the price list isnot empty, then the average auction price is calculated, as indicated byblock 630, and as described in greater detail with reference to FIG. 31.Next, the orders are matched such that the minimum number of tickets aregenerated, taking into account the credit preferences of all parties, asindicated by block 632, and as described in greater detail withreference to FIGS. 32A and 32B. Once the orders have been matched, asettlement list is generated, representing the execution of transactionsvia the option, as indicated by block 634.

[0360] With reference to FIG. 31, the average auction price iscalculated. In particular, beginning at block 640, the initialparameters are established, such as i=1, j=1, difference equal s1−b1,k=2, and N=size of price list. In addition, the total amount in theBuyList is B₁, and the total amount in the SellList is S_(N−i+1). Next,it is determined at block 642 whether k=N+1. If so, then the averageauction price is P_(I). If it does not, then it is determined at block644 whether difference is greater than 0. If it is, then parameter j isset to j=j+1, the parameter difference is set todifference=difference+B_(J), and the parameter k is set to k=k+1, asindicated by block 646. If not, then the parameter i is set to equali=i+1, the parameter difference is set to difference=difference+S_(i),the parameter k is set to k=k+1, as indicated by block 646. The steps ofblock 642-648 are repeated until determination is made at block 642 thatk=n+1.

[0361] With reference to FIG. 32, the step of matching orders in anauction is described in greater detail. In particular, items in theBuyList and SellList are eliminated according to the average auctionprice, as indicated by block 650. It is then determined at block 652whether the size of BuyList is greater than zero and the size ofSellList is greater than zero. If one or the other is not greater thanzero, then the settlement list is generated, as indicated by block 654.If both the BuyList and SellList are greater than zero, then theparameter Bsum is set to equal the total volume in BuyList and Ssum isset to equal the total volume in SellList, as indicated by block 656. Itis then determined at block 658 if Ssum is greater than the Bsum. If itis, then the parameter list1 is set to equal SellList and the parameterlist2 is set to equal BuyList, as indicated by block 660. Next, theorder1 parameter is set to equal to the first order in list1 and order1is removed from list1, as indicated by block 662. The maximum/minimumand credit rules are then applied to search the BuyList for matchingorder2. A matching order2 is located and a trade is generated betweenorder1 and order2, as indicated by block 666. If at block 668 it isdetermined that Ssum is not greater than Bsum, then parameter list1 isset to equal BuyList and list2 is set to equal SellList, as indicated byblock 668. Next, order1 is set to equal the first order in list1 andorder1 is removed from List1, as indicated by block 670. Next, list2 issearched in order to find a match to order1 using the maximum-minimumrule and the credit preferences associated with the orders, as indicatedby block 672 and described in greater detail with reference to FIG. 33.A trade is then generated between order1 and order2, as indicated byblock 674.

[0362] With reference to FIG. 33, the application of the maximum-minimumrule and credit rules satisfying an order are described in greaterdetail. Initially, it is noted that the parameter volume is equal to thevolume of an order, and more particularly, of order1. At block 680, itis initially determined whether the parameter volume equals 0 fororder1. If it does not equal zero, then it is determined at block 682whether list2 is empty. If list2 is not empty, then list2 is searchedfor the first matching order, as indicated by block 684. Once a matchingorder is located, then the volume traded will equal to the minimum asdefined by the credit preferences of either party, the volume of order1,or the volume of order2, as indicated by block 686. It is thendetermined if the trade volume is 0, as indicated by block 688. If thetrade volume is 0, then the process begins again at block 680. If thetrade volume is not equal to 0, then a trade is generated and placed inthe settlement list, as indicated by block 690. In addition, at block692, order2 is removed from list2. Next, the volume of order1 and order2are updated by setting the respective volumes to the previous volumesminus the trade volume, as indicated by block 694. It is then determinedat block 696 if the volume of order2 is equal to zero. If it is not,then order2 is placed back in a temporary list and a credit of theparties placing order1 and order2 are updated, as indicated by block698. Once the volume of order1 is determined to be zero, then it isdetermined at block 702 whether the temporary list is empty. If it isnot, then the temporary list is merged with the BuyList, as indicated byblock 704. Subsequently, the process ends.

[0363] The operation of the central processing center 12 is nowgenerally described with reference to FIG. 34 which functionally depictsthe group server mechanism 32, the auction mechanism 34 and switchmechanism 35, the market inventory module 38, the execution module 40,and the settlement module 42. A legend 710 is provided to the denote theflow of the different orders, interactive and switch orders, auctionorders, and switch auction orders, between the group server mechanism32, the auction mechanisms 34, the market inventory module 38, theexecution module 40, and the settlement module 42. Beginning with theinteractive/switch order generated by the user at one of the traderworkstations 20, the central processing center 12 initially receives theinteractive/switch order 712 at the group server mechanism 32. At thegroup server mechanism 32, an order record is created, the creditpreferences of the users are checked to assure the trade conforms to thecurrent credit preferences of the users, and a transaction order iscreated. If the order is passive, then it flows through to the marketinventory module 38 where is it distributed to the trader workstations20 for viewing via respective market detail interfaces 302 of the userslogged on the system 10. If the order is active, then it flows throughto the market inventory module 38 where order matching occurs if theorder is a part of an auction, and pre-execution of the order alsooccurs. Pre-execution may include, for instance, a back-end credit checkto ensure up to date credit preferences and to accommodate complexchecks. Further, in a manner that is transparent to the users, themarket inventory module 38 requires the trader workstations 20 of therespective users that are a party to the trade to respond with anacknowledgement to assure that there has been no loss of communicationor that one of the users has not logged off. Upon receiving theacknowledgement, the market inventory module 38 executes the trade andthen publishes the updated volume and status to the users logged on tothe system 10 for viewing via respective command center interface 130 ofthe users.

[0364] Next, the execution module 40 will, upon request of one of theusers that were a party to the trade, enables the quantity of the tradeto be increased via the will-do-more feature. This will typically be thecase unless the full quantity of the instrument is transacted.Otherwise, the execution module will initiate the confirmation processwhich includes an opportunity for either of the users that were a partyto the trade to enter into term negotiations.

[0365] The order the flows through to the settlement module 42 whichinitiates the settlement process. The settlement module allows forsymbol explosion by the users to view the exact terms of the contract.Further, a settlement module calculates the commission based upon theorder which ends the process, thereby noting the end of the orderexecution process.

[0366] In the case of an auction, an auction order 714 received by theauction mechanism 34. The auction module 34 enables auction and switchauction functionality of the present invention. The auction moduleinitially receives the auction orders 714 a from a plurality of usersduring a countdown to the actual auction time. Once the auction time hasarrived and the auction orders have been submitted, the auctionmechanism 34 performs the auction matching with credit preferences ofthe users taken into account. The auction matching performed by theauction mechanism 34 is in accordance with the present invention, thatis, the auction is based on a fair price and executed for a maximumvolume traded with a minimum number of tickets generated. From theauction mechanism 34, once the counterparties have been matched themarket inventory server essentially treats the resulting auction ordersas though it would an interactive/switch order 712. In particular, themarket inventory module 38 perform order matching, pre-execution,acknowledgement, trade execution and volume/data publishing.

[0367] The auction order 712 is then delivered to the execution module40. At the execution module 40, an auction order and a switch auctionorder are traded slightly different. For instance, an auction order maybe increased in quantity by one of the users that is a party to theauction order via the will-do-more. On the other hand, switch auctionorders do not make use of this feature, but will go directly to theconfirmation process. Further, where auction orders may also have theirnon-commercial terms negotiated using the term negotiation feature,switch auction orders will flow to the settlement module 42 directlyafter confirmation. Both auction orders and switch auction order arethen received by the settlement module 42 which performs essentially thesame operations to the auction order as it does to an interactive/switchorder 712. Specifically, the settlement order 42 provides similarexplosion and commissioned calculations which complete the orderprocess.

[0368] In the drawings and specification, there have been disclosedtypical preferred embodiments of the invention and, although specificterms are employed, they are used in a generic and descriptive senseonly and not for purposes of limitation, the scope of the inventionbeing set forth in the following claims.

Wherefore, the following is claimed:
 1. A system for credit screening anelectronic trade of a financial instrument between a first trader and asecond trader, comprising: means for receiving first credit preferenceinformation of said first trader with respect to said second trader,wherein said first credit preference information relates to at least onefinancial instrument; means for receiving second credit preferenceinformation of said second trader with respect to said first trader,wherein said second credit preference information relates to at leastone financial instrument; means for evaluating said first and secondcredit preferences with respect to a trade of a first financialinstrument to determine respective trade eligibility of said first andsecond traders to trade with each other; and means for reporting saidrespective trade eligibility to said first trader and said secondtrader.
 2. The system of claim 1, wherein said means for reportingincludes a first indication representing that said first and secondtraders will trade with each other, a second indication representingthat said first trader will trade with said second trader but saidsecond trader will not trade with said first trader, and a thirdindication representing that said second trader will trade with saidfirst trader but said first trader will not trade with said secondtrader.
 3. The system of claim 1, wherein said means for reportingincludes a color coding scheme for presenting said first, second andthird indications respectively to said first and second traders.
 4. Thesystem of claim 3, wherein said color coding scheme includes a firstcolor associated with said first indication, a second color associatedwith said second indication, and a third color associated with saidthird indication.
 5. The system of claim 1, wherein said first creditpreference information is defined in terms of a yes/no statement.
 6. Thesystem of claim 1, wherein said first credit preference information isdefined in terms of maturity of a financial instrument.
 7. The system ofclaim 1, wherein said first credit preference information is defined interms of a risk equivalent.
 8. The system of claim 7, wherein said riskequivalent is automatically determined by said system.
 9. The system ofclaim 1, wherein said first and second credit preference information ismaintained in anonymity.
 10. The system of claim 1, wherein said firstand second credit preference information can be updated in essentiallyreal-time by said first and second traders, respectively.
 11. A methodfor screening order information proposing a trade of a financialinstrument via an electronic trading system, comprising the steps of:receiving first credit preference information defined by a first traderwith respect to a second trader; receiving second credit preferenceinformation defined by the second trader with respect to the firsttrader; and encoding the order information that is presented to thefirst and second traders proposing a trade utilizing the first andsecond credit preference information.
 12. The method of claim 11,further comprising the step of modifying the first credit preferenceinformation by the first trader.
 13. The method of claim 11, whereinsaid step of encoding includes a first indication representing that thefirst and second traders will trade with each other, a second indicationrepresenting that the first trader will trade with the second trader butthe second trader will not trade with the first trader, and a thirdindication representing that the second trader will trade with the firsttrader but the first trader will not trade with the second trader. 14.The method of claim 11, wherein the first credit preference informationand the second credit preference information are defined as preferenceswith regard to at least one financial instrument.
 15. The method ofclaim 11, further comprising the step of maintaining the first andsecond credit preference information in anonymity.
 16. The method ofclaim 11, wherein said step of receiving the first credit preferenceinformation includes the step of receiving first credit preferenceinformation that is defined in terms of a yes/no statement.
 17. Themethod of claim 11, wherein said step of receiving the first creditpreference information includes the step of receiving first creditpreference information that is defined in terms of maturity of afinancial instrument.
 18. The method of claim 11, wherein said step ofreceiving the first credit preference information includes the step ofreceiving first credit preference information that is defined in termsof a risk equivalent.
 19. The system of claim 18, further comprising thestep of determining the risk equivalent automatically by the electronictrading system
 20. A computer program product for use with a dataprocessing system for credit screening order information proposing atrade of a financial instrument via an electronic trading system, saidcomputer program product comprising: a computer usable medium havingcomputer-readable code means embodied in said medium, saidcomputer-readable code means comprising: computer readable program codemeans for receiving first credit preference information of said firsttrader with respect to said second trader; computer readable programcode means for receiving second credit preference information of saidsecond trader with respect to said first trader; computer readableprogram code means for evaluating said first and second creditpreferences with respect to a trade of a first financial instrument todetermine respective trade eligibility of said first and second tradersto trade with each other; and computer readable program code means forreporting said respective trade eligibility to said first trader andsaid second trader.
 21. The computer program product of claim 20,wherein said computer readable program code means for reporting includesa first indication representing that said first and second traders willtrade with each other, a second indication representing that said firsttrader will trade with said second trader but said second trader willnot trade with said first trader, and a third indication representingthat said second trader will trade with said first trader but said firsttrader will not trade with said second trader.
 22. The computer programproduct of claim 20, wherein said first credit preference informationdefines preferences with regard to a single financial instrument. 23.The computer program product of claim 20, wherein said first creditpreference information is defined in terms of a yes/no statement. 24.The computer program product of claim 20, wherein first said creditpreference information is defined in terms of maturity of a financialinstrument.
 25. The computer program product of claim 20, wherein saidfirst credit preference information is defined in terms of a riskequivalent.
 26. The computer program product of claim 20, wherein saidrisk equivalent is automatically determined by said system.
 27. Thecomputer program product of claim 20, wherein said first and secondcredit preference information is maintained in anonymity.
 28. The methodof claim 11, wherein said step of encoding includes an indicationpresented to the first trader representing that the first trader willtrade with the second trader but the second trader will not trade withthe first trader, further comprising the step of providing a creditover-ride process that allows the first trader to deal with the secondtrader directly if the second trader agrees.